Welcome to whitepaper Discussions!

[oa-sarvesh]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[msantore]

Hello,

I'm Michael Santore, founder and CEO of BlockSkunk. We build the multi-party system of record for regulated industries: one shared, cryptographically verifiable record alongside everyone's systems, so counterparties stop reconciling five versions of ownership, settlement, and rules. Our risk register embeds compliance controls into a permissioned ledger.

I joined via the LFDT session on institutional tokenization. We see the same failure mode OTAS names: fragmented formats, trapped collateral, and duplicated compliance. Standards belong at the seams (identity, compliance, metadata, settlement), not inside any one stack.

Today we focus on SEC/FINRA RIA workflows, with ISO 27001, EU AI Act, and SOC 2 Type 2 evidence paths designed for cryptographic attestation. Next up: GENIUS and MiCA compliance and Real Estate workflows, with a strong emphasis on enterprise data governance.

Looking forward to contributing on the discussions and supporting the community.

-- Michael

[oa-sarvesh]

Welcome, Michael — really glad you found us through the LFDT institutional tokenization session, and thanks for the thoughtful introduction.

You've put your finger on exactly the thesis OTAS is built around: the standard belongs at the seams — identity, compliance, metadata, settlement — not inside any one stack. That's the whole bet, so it's great to have someone thinking the same way join the conversation.

Given where your work sits (SEC/FINRA, ISO 27001, SOC 2, and the MiCA/GENIUS paths you're building toward), a few of our open questions look right in your wheelhouse — I'd love your take on any of them:

• Compliance reason-code taxonomy — can we agree on a stable, machine-readable set of compliance reason codes that map cleanly onto FATF / MiCA / BSA-AML? Your regulated-workflow experience would be especially valuable here.
• Metadata canonicalization — how far the core descriptor should align with ISO 20022 / FIX / FpML, which connects to your data-governance focus.
• Referencing incumbents — how OTAS should reference rather than replace existing rails, i.e. your "seams, not inside any one stack" point made concrete.

They're all in the Discussions tab under Q&A. Jump into whichever resonates — even a challenge to an assumption or a pointer to prior art is genuinely useful. Looking forward to your input.

We'd also love to have you at our monthly OTAS community call — it's an open forum, and hearing your perspective on the compliance and metadata layers live would be a great addition. I'll make sure you have the details. Looking forward to having you in the mix.

[msantore]

Thanks @pv-sarvesh - Will aim to join the next monthly call and follow the Q&A threads.

One adjacent idea: NIST OSCAL may be worth exploring at the security-control evidence seam. Not for FATF/MICA/BSA codes, or 20022/FIX/FpML, but as a clean way to attach control findings to an OTAS workflow without pulling the standard inside a control stack.

https://github.com/usnistgov/oscal

[MukulKolpe]

Thanks so much, @msantore, and delighted you'll be joining the next community call.

OSCAL is an excellent pointer, and the way you've scoped it is exactly right: not the AML/CFT codes, not the instrument semantics, but the security-control evidence seam. That's genuinely where the draft is thinnest, so this is a helpful nudge. Today it's a SOC 2 PDF exchanged during onboarding diligence.

The attach-by-reference framing is the part that appeals, keeping the evidence itself outside the standard and referencing it, rather than pulling control logic in.

One thing we'd value your view on: control evidence attaches to an operator or venue, not a party to a transfer, so it may sit somewhere other than the identity layer. The expiry semantics differ too: an assessment covers a window that has closed, where an eligibility credential is valid or revoked at the moment of the check.

Thanks again for engaging so substantively straight away. Looking forward to having you on the call.

[307sagar]

Hi,

I am Amit, working with a Central Bank on wholesale payments.
I have to say a very comprehensive start !

Couple of points that might add more clarity on some of the layers that you have got in there.

• Settlement networks : settlement layer should guarantees the
  1.Technical Finality, and - this is mostly covered under atomic settlement

2. Legal Finality - needs more generalised approach on standards on compliance, specifications/rule books for a legal construct to define settlement.
   Different jurisdictions has different definition of them : how to guarantee settlement finality - is it point of irrevocability or point of final settlement. Food for thought - https://www.bis.org/cpmi/publ/d101a.pdf
   Principle 8: Settlement finality
   An FMI should provide clear and certain final settlement, at a minimum by the end of the value date. Where necessary or preferable, an FMI should provide final settlement intraday or in real time.
   Some of the considerations -
3. FMI’s rules and procedures should clearly define the point at which settlement is final.
4. An FMI should clearly define the point after which unsettled payments, transfer instructions, or other obligations may not be revoked by a participant.

Suggestion on 'Standard should/shouldn't do' : SettlementProposed (Technical SF && Legal SF constructs) -> Committed| Settled | Aborted - there can be a scope to use both technical finality and legal finality inputs as parameters to have a safe method.
□ Settlement coordinator - after receiving both the party's atomic legs states - it should be in committed state. That gives the guarantee that the transaction is enqueued and will not be lost.[thinking from a payment processing angle]

□ For Interoperability - I have seen mentioning of various forms of solutions, and not cryptographic proofs/light clients to interoperate. Would it be worth exploring generic standard for message constructs that can be helpful for improving hetero systems communications ?

Happy to speak on the next community call.

Thanks !

[MukulKolpe]

Thanks @307sagar, this is a valuable addition, and great to have you here.

You've named the gap precisely. Section 6.1 treats atomic settlement as the whole finality story, but that's only technical finality. Legal finality is separate and jurisdiction-dependent, and as you say, the point of irrevocability and the point of final settlement aren't always the same moment. PFMI Principle 8 is the right anchor, and distinguishing "when may an instruction no longer be revoked" from "when is settlement final" is a distinction the current text collapses. It belongs in the settlement layer explicitly. The PFMI link looks like a good read on exactly this; appreciate you sharing it.

Your state-model suggestion is a real improvement. The draft's lifecycle is SettlementProposed -> Settled | Aborted, which has nowhere to express the guarantee you describe. A Committed state seems like a good proposal; once the coordinator holds both legs' states, the transaction is enqueued and won't be lost, even before final settlement. It also gives legal finality somewhere to attach, since the revocability boundary can sit at the transition into Committed. Treating technical and legal finality as distinct inputs to the transition, rather than assuming atomicity implies both, is the right shape.

On interoperability, the draft lists bridging mechanisms (HTLC, escrow/notary, shared-ledger) but says little about the message layer beneath them, how two heterogeneous systems express and verify a settlement instruction's state in the first place. That common message construct feels like the more tractable thing to standardize; the underlying verification approach, cryptographic proofs among them, is less settled, with finality models and proof formats varying enough across ledgers that it's probably too early to standardize on one. Worth separating the two.

Would be great to have you on the next call to work through the finality distinction. Thanks again.

[RamVaz]

Hello,

A quick intro as this is my first comment on the project - My professional experience includes working at traditional financial firms offering middle office services to institutional investment firms and at crypto infrastructure companies powering a wide variety of use cases, including trading and settlement.

I am currently most interested in the adoption of tokenization and the various approaches by networks, trading venues, and service providers. I am intrigued by what the OTAS community is working towards and hope to contribute in some meaningful way. For now, just some feedback on the current version of the whitepaper:

A few positives to start:

1. Very clear and concise definition of the scope and four layers that are being focused on (Settlement, Identity, Compliance, Asset Metadata)
2. Very informative and useful comparative of analysis (4.6, 5.3, 7)

Here is where I was less clear - Section 8. Reference Flows

I am still trying to conceptualize where OTAS fit in the end to end flow of customer onboarding, trade matching, trade settlement.

Looking at Flow A (Cross-rail DvP of a tokenized sovereign bond against a tokenized deposit):

I thought OTAS was focused on the 'The post-trade lifecycle' (3.1), yet this flow (A.3) seems to reference 'canTransfer (pre-trade check)' which I believe is the EVM function and not an OTAS standard used in post-trade settlement. I believe the next step (A.4) is where OTAS is being used where the 'SettlementProposed' attribute is referenced.

So in summary, and only if my assumptions above are accurate, I think more clearly defining where OTAS is being applied by writing a little about how and when the on-chain values are mapped and generated to OTAS would be beneficial.

[MukulKolpe]

Welcome @RamVaz, and thank you. Glad the scope, the four-layer breakdown, and the comparatives (4.6, 5.3, 7) landed. This is exactly the kind of reader feedback that shows us where the paper assumes context it hasn't earned yet. Your background is going to be valuable here, so I hope this is the first comment of many.

You've caught a genuine ambiguity in Section 8, and I think you're largely right. Let me clarify, and I suspect the clarification itself points to a real edit for the next revision.

On canTransfer: In the flows, this refers to the OTAS compliance-signaling interface proposed in Section 6.3 (canTransfer(from, to, amount, context) -> {allow | deny + reason-code}), not the EVM reference specifically. ERC-3643 does define a function called canTransfer, and section 6.3 deliberately borrows the name because it's the most widely recognized expression of the pattern. But what OTAS standardizes is the compliance-signaling interface and its result semantics: given (from, to, amount, context), return allow or deny-with-a-standard-reason-code, not any particular chain's function. Each rail then binds that interface natively: on EVM it happens to also be called canTransfer (ERC-3643), on Sui it's a TokenPolicy rule resolved via ActionRequest, on Solana it's a transfer hook, and so on. Section 5.3's mapping table does exactly this for the Restricted behavior, but you're right that Flow A never says so, and a reader can reasonably conclude A.3 is chain-specific plumbing and that OTAS only "starts" at A.4. It doesn't: steps A.2 through A.5 are all OTAS interfaces (eligibility verification, compliance check, the settlement lifecycle, and the canonical events). What varies per step is only which rail-native mechanism implements each one.

On the "pre-trade check inside a post-trade standard": The check is essentially pre-settlement, not pre-trade. It runs after the trade is agreed and before anything locks, and its purpose is entirely post-trade: discovering that a leg would fail before capital is committed, rather than at settlement, is what makes the later atomic guarantee cheap. We should probably rename it "pre-settlement check" in the flows to kill the ambiguity, noted.

And your closing suggestion is the most valuable part. We don't currently explain how and when a raw on-chain token becomes an OTAS-modelled object, when its base type, behaviors, and capability manifest are mapped or generated. That's a genuine gap. In practice that mapping is either native (the token is issued to conform) or observed (tooling reads on-chain facts and normalizes them into the OTAS model). A short subsection making that explicit, and threading it into the flows, would directly address what you found unclear, and we'd like to fold it into the next iterations.

Thank you!

[RamVaz]

Hello @MukulKolpe

Thank you for considering my feedback and providing your thoughtful responses above. I now better understand these narrative flows in Section 8, thank you.