This article’s genesis is a long X post reply that I provided on a very insightful article authored by a former corporate attorney turned cypherpunk lawyer on what Native Tokenization means.

I am fully onboard the taxonomy of tokenization types espoused in that article: synthetics, pointer vs constitutive and most of the other ideas discussed it. Below I offer some different points of view on some of the statements / premises brought forward, in the hope they have some merit for consideration and enrich the dialogue - nobody has all the answers, but together we can come up with better solutions. I use quotes for content I copied from that article.

A. Constitutive Tokenization and a Single Register -> the Myriad of Copies won’t go away

“There is one register, and it is the chain.”

I would adjust that to: There will continue to be multiple registers of ownership (for the same assets) but the ultimate source of truth (enforceable through law) is the chain.

Speaking from former experience in architecting systems at Options Clearing Corporation and DTCC, I can say with certitude that there are many copies of registers of ownership (i.e. positions) in the financial markets.

A clearing house is a transfer agent (TA) on steroids so what I talk about below, I think is very applicable to TAs as well - just at a smaller scale. And while the following statements focus on US markets & entities & listed equities (and their listed derivatives), similar concepts apply to markets in other parts of the world and other asset classes.

DTCC splits the ultimate source of truth between 2 layers: the legal layer (Cede & Co) and the operational layer (the Book-entry system or Participant Ledger)

gemini.google.com/share/dbb8db10…

Options Clearing Corp does not have a corresponding legal layer but it has a similar operational layer for the source-of-truth ledger: the derivatives contracts inventory held in OCC’s Clearing Members accounts.

gemini.google.com/share/24aa9a7d…

While we can view the above registers as the source-of-truth registers (the kind of registries that in the ultimate state we aim to be hosted on blockchains) there are a myriad of registers that mirror (are a reflection/copy of) either the full source-of-truth registers or subsets of it. Main examples:

  • Clearing Members (i.e. mostly brokerage houses) - will have a copy of all positions and trades + post-trades for all the activity they are involved with: their firm, their customers, other entities that clear through them, etc.

  • Service Bureaus - entities that provide tech services to smaller clearing members.

  • Regulators - e.g. SEC or CFTC are often interested to have a full view on trading activity and risks across entire markets and over position books across multiple clearing houses; see for e.g. the big industry push after 2008 to bring in more OTC products into central clearing.

Now why do all these entities keep their own registries of ownership? Non-exhaustive list of reasons:

  • Technical and operational reasons: it is easier, faster, more cost efficient to query your own database of records (a database that stores only records / activity your entity is interested it) -> I think this will continue to be very much applicable in a blockchain world: especially for chains like Solana’s that maintain very large ledgers.

  • Exceptions and recovery reasons: since double-entry accounting was introduced in medieval times humans found out that booking the same type of activity twice can make a booking system more reliable and the detection of booking errors easier. If everyone was to use just the single source of truth register for their needs, transactions done in error (and many things can go wrong when building and operating a booking system) the lack of balancing/reconciliation to another register would likely make these errors harder to detect and recover from.

  • Sub-ledgering: many accounts/buckets in the source-of-truth registers act as omnibus accounts - they require the traversal of downstream layers to breakdown inventory to arrive at the ultimate owner.

  • Aggregation: as in the example of regulators discussed above, in certain use cases there is a need to aggregate data from multiple ultimate source-of-truth ledgers.

I don’t see the world of many copies of books of ownership going away any time soon. And yes, the business/costs for providing the tech that can do the copying and keeping in sync of these copies will still be substantial - but would be made more efficient when the technology used for maintaining the ultimate source-of-truth moves to blockchains. As an example, just take a look at the Solana’s RPC infrastructure (built around standardized interfaces) that can be used for real-time and batch reads of blockchain state and history + the general access for anyone to build their own data extraction / sync layer directly on top of the blockchain data.

Maybe Gabriel did not really mean to imply that these type of copies would stop existing. It was not clear though from the article that he left room for them - hence my desire to shed some light into this.

B. Addition to the Walkaway Test -> What is the primary source of trust for a maintainer of records of ownership?

“ If you walked away from the offchain infrastructure (transfer agents, issuer’s database, platform), would the security still exist with full legal effect on the chain alone.“

Fully agreed on the Walkaway Test - I would just add that the copies I have talked about can also be a fallback mechanism for the “Material Adverse Exception Events - accounting for extraordinary compromises” he talked about, when blockchains themselves have hiccups. Probably a very messy process to try to repair a compromised blockchain from offchain copies - in the very very low likelihood for that to happen - but still, some fallback mechanism would exist.

I would add one more test: starting with the assumption that most (if not all) maintainers of records of ownership onchain would still have offchain records/mirrors - if required by external parties to produce reports/extracts on this data, where would they go first to extract that data or point the interested party to get the data from? Or if they would detect discrepancies between their offchain records and the onchain ones, which source of data is to be assumed initially to be correct? If the answer is the blockchain, then that is another smell test that passes the constitutive tokenization bar.

Basically, it is a matter of what does the maintainer of books and records trust first.

C. The blockchain as the one-stop shop -> it is impractical for the blockchain to hold and/or do everything

“Only in this model (constitutive) the blockchain contains everything needed for the securities.”

I’ve seen this often across the Defi ecosystem - the desire and the belief that everything can be done on the blockchain:

  • the blockchain can enforce all business rules, verifications, have access to all the needed data (and thus one can fully codify onchain) to perform the settlement of regulated assets in a compliant and legal manner

  • the entire lifecycle for the trade execution layer (i.e. exchange functions: matching a buyer and a seller) can be fully done onchain -> even for the most stringent HFT needs currently existing on TradeFi; I won’t focus on the possible issues here - topic for another discussion; instead discuss just the settlement layer.

Why do I think this will prove to be impractical and hit walls in implementation (thus come short of expectations)?

  • For good reasons, blockchains impose tight technical constraints in terms of what programs/smart contracts can do: the amount of input data they can consume (or from where to consume it: typically a program can only read data already onchain) and amount of output data they can produce, the amount of compute that can be used to execute the code and the max allowed time for a transaction to complete.

  • Some of the input data can be (quite) more cost inefficient to be maintained on and consumed from onchain vs handling this offchain: e.g. data that changes very frequently (e.g. high frequency quotes or very high velocity price feeds) with much of those updates not leading to economic outcomes that bring back revenue to the chain/user (i.e. a materialized trade that can cover for the costs of making the updates) OR large documents needed to fully express the rights required to conduct settlement.

  • Gabriel’s “Intermediary Cosplay Tokenization” article was really good in clarifying that the token/security does not have regulatory obligations. The regulated parties involved do. Looking at the statement below from the same article, there is a fair amount of non-deterministic ruling that falls on the regulated party to arrive at a decision that something can be done or not. How does one then even codify that in an smart contract?

“The architecture of this regime is intentionally principles-based. The CDD (Customer Due Diligence) requirements applicable to broker-dealers under 31 CFR § 1023.210 require “risk-based procedures,” not deterministic rules. Institutions are expected to collect more information for higher-risk customers and may collect less for lower-risk ones, “as appropriate.”“

What should blockchains do?

With this said, below is a proposal for what blockchains could be limited to host and do - to get to a Constitutive Tokenization state (for regulated assets):

  1. Maintain a record of who owns what, and how much of it.

  2. As little information as possible to tie the blockchain address/wallet to the owner (be that an ultimate owner or a registered entity for omnibus record-keeping models): e.g. PII identifiers (LEIs, SSN, etc).

  3. Provide a mechanism to tie encumbrances to owned assets so the non-collateralized portion of an owned asset + the location of the pledges can be easily determined (the article’s section on Kamino + Super State integration is a very good reflection of shortcomings of the Pointer Tokenization model).

  4. Provide a mechanism through which an entity (a regulated entity - e.g. a TA or the asset owner where possible) that can effect the movement of an asset onchain can attest that this entity has done all the necessary offchain verifications that make the movement of the asset compliant and legal. So the verifiers only provide the verification attestation itself onchain but they DO NOT DO the verification itself onchain - they can do whatever is needed offchain to arrive at the greenlight.

  5. A corollary to 4 is that a registry of allowed verifiers needs to be maintained onchain - that can be accessed by onchain smart contracts to check that the verifier(s) are approved verifier(s) who are entitled to give the greenlight for the movement of the asset in question between the stated source and destination wallets/accounts.

  6. Enforcement of privacy: all data that can be deemed as requiring privacy (e.g. the PII at 2, the account balances at 1, transfer amounts, etc) should be controlled and disclosed as clear text on a as needed basis, only to parties approved by the asset owner or required by law (Gabriel covered this well too in his article).

  7. Ideally standardize the master file security definition of onchain assets - i.e. have standards for how the attributes of a financial instruments should be expressed onchain, and what+how can be stored offchain and where offchain. See the FIX protocol and ISO 20022 for successfully efforts going on for decades in the TradeFi world.

An additional point on item 4: I view the movement of securities in the US markets as a movement within a “walled garden” -> when securities are moved from one place to another they are moved only through and to locations where some sort of regulated entity is involved with some sort of responsibility and control over the transfer activity. i.e. these assets can’t be moved freely outside of the walled garden perimeter; hence the need for a registry of approved verifiers.

Item 3 increases substantially the chances for Constitutive Tokenization to see the light of day at scale, compared to the having the blockchain do and store everything approach.

I realize that many of these items are a tall order and their implementation is not an easy feat. However the tech capabilities provided by blockchains, public/private cryptography and more recent developments in the ZK space can make all this feasible - albeit with still a large amount of work and industry participants coordination.

I would love to see feedback that builds upon/enhances this list or brings good points of critique. More narrow, well defined and agreed upon (again tall order) goals can help us move faster.

D. The Ethereum over Solana part of the verdict -> Likely too early to make a call on that

I believe Gabriel and I are pulling from the same side of the cart: if it is Ethereum or Solana or a Canton or a Ripple or (more likely) a combination of these that can take us to where we want to be - that is the main/important goal and not exactly which of these blockchains will win.

These observations are counterpoints from someone who comes in with a Solana bias and not enough knowledge of the Ethereum ecosystem (but open minded to learn more):

  1. The arguments on decentralization and uptime between the 2 networks I think at some point become religious. Are both at the point where one could consider running the SWIFT network on them? In my opinion, very likely. Does either have a tech support line to call in if something goes wrong? No. And that is something for TradeFi to grapple with as it considers moving into a new world where the trust in specific entities for the reliability of the systems it runs on, shifts to a more diffused and decentralized model - but a model which gets to be more open, battle tested and audited than today’s proprietary systems.

  2. Ossification, stability and speed of changes: I agree this is a very important aspect to consider for financial systems. I found Solana’s validators ecosystem and client builders (Anza and Firedancer teams) to be fairly cautious and conservative about not deploying changes that break things or bring in significant backwards compatibility issues. I favor instead the ecosystem’s relentless attention and efforts towards its IBRL goals. From my experience, when building large systems one of the most difficult thing to improve is the ability to scale (on whatever dimension you want to look at scale: throughput, latency, etc). As far as I am concerned, it is very important if a settlement system can arrive at finality within a second vs over 10 seconds. And also, if it can compete with Visa in throughput or not.

  3. For account structure changes in Solana: not too much different than building an offchain system - yes, your system can evolve and you might need to migrate your data structures over time. With good design you can reduce the rate of needed changes and, regardless, this is a known problem space that we know how to tackle -> it can involve though more the need to use permanent delegate type of keys that have “god-like” permissions to change onchain accounts: a problem unique for blockchains.

  4. I agree: there is more sophistication in the Ethereum ecosystem in terms of arriving at standards that get us closer to requirements called for in the Constitutive model. Also a less concentration on common and widely deployed implementations: maybe something that partially explains the larger transaction activity volume in Solana (arguably though, when looking just at RWAs, that advantage dissipates). I also agree that there are many shortcomings (when viewed from the prism of the lofty goals I laid out) that need to be addressed with Token 2022 Extensions - and hoping to see significant upgrade with a 2027 standard. Regardless though, nobody stops a team from cloning the Token 2022’s program and making a bunch of enhancements as it sees fit. But from what I have seen in my experience in the TradeFi markets, shifting from working in isolation on a large enough problem (i.e. that many participants have) to a community driven effort (or at least participation or involvement with feedback from the community) has much higher chances of success.

My exploration of deep and not-often talked about corners that sit at the intersection of TradFi and Defi ecosystems takes a break here. I would love to see more future discussion around topics like these.