Most "Tokenized Securities" Are Intermediary Cosplay — Time to Really Put Securities Onchain

Intro

The security token industry spent the better part of a decade building compliance infrastructure for tokens that aren't securities, enforcing regulations on behalf of entities that never delegated their obligations to a smart contract, and solving for regulatory requirements that don't exist in the form the architects assumed. The engineering was competent. The premises were wrong. The result betrayed the core value proposition of the technology it was built on.

The promise of putting securities on blockchains was never "the same intermediary chain, but on Ethereum." It was disintermediation: reducing the number of trusted third parties standing between a stockholder and their ownership record, collapsing settlement layers, enabling peer-to-peer transfer and self-custody of financial instruments that have historically required a stack of brokers, transfer agents, custodians, and CSDs just to move from one person to another. The private stock market, where most tokenized securities live, is a case study in intermediary-created friction: transfer agents who take weeks to process a transfer, cap table software that constitutes a single point of failure, legal opinions required for every resale of restricted stock, information asymmetries between issuers and holders, and the near-total absence of price discovery or liquidity for all but the most elite private companies. Blockchain technology was supposed to address these problems. The security token protocols reproduced them, dressing intermediaries up in smart contract costumes and calling it tokenization.

ERC-3643, ERC-1400, ERC-7943, Securitize's DS Protocol: all of them started from the same vague, unexamined assumption: "this token is a security, so we need to make it compliant." They never clearly established what the token is as a matter of law, never identified who actually bears the compliance obligations they were purporting to automate, never checked whether the modality of regulation they were encoding (transfer restriction at the token layer) is even the primary way securities are regulated, and never asked whether their architecture actually reduces reliance on intermediaries or merely adds a new layer of smart contract complexity on top of the existing intermediary stack. They got the ontology wrong, the obligated party wrong, the regulatory modality wrong, and the disintermediation thesis wrong, then shipped the result as infrastructure.

And the problem isn't confined to token-level design choices on public chains. Some architects drew an even more radical conclusion from the same false premises: that securities are so incompatible with public blockchain execution environments that the entire VM and ledger model must be rebuilt from scratch. Digital Asset's DAML language and the Canton Network represent this camp, a purpose-built permissioned execution environment whose sub-transaction privacy and semantic authorization model are presented as regulatory necessities. The regulatory frameworks they invoke don't actually mandate what they built, any more than ERC-3643's compliance modules discharge the obligations they purport to automate. The error is the same at both scales: misidentifying what regulation requires, and then building technical apparatus to satisfy the misidentification.

The Ontological Confusion

The first false premise is the most basic: these protocols never clearly established what the token is as a matter of law.

I've written separately about the different legal relationships a token can have to a security ("5 Ways of Tokenizing Securities (& One Which is Best)"). The taxonomy is essential to understanding why the security token protocols are misengineered, because the engineering choices you make depend entirely on which relationship you're building for. Compressed:

1. The chain-as-ledger model

The corporation's governing documents designate the blockchain as the official stock ledger. The token IS the ledger entry. Holding it makes you the stockholder of record. The onchain state is the legal state. This is the model that fully leverages what blockchains actually do (create finality) and it fits cleanly with DGCL §§ 219 and 224, which since 2017 have explicitly authorized corporations to maintain stock ledgers on distributed electronic networks. This is the approach I consider optimal.

2. Certificate tokens

The most intuitively cryptonative model: the token is an electronic analog of a paper stock certificate. Beautiful in concept, but blocked by the Uniform Commercial Code. As far as certificated securities go, UCC Article 8 only recognizes them in paper form; the ESIGN Act's general mandate of electronic equivalence is explicitly carved out for UCC-governed transactions. Wyoming is a partial exception, but the interplay with Article 8 for secondary transfers and secured lending is legally untested. Building production infrastructure on a legal theory that requires law reform is aspirational lawyering, not responsible engineering.

3. Instruction tokens

Under UCC Article 8, an "instruction" is a notification to the issuer of uncertificated securities directing a change in registered ownership. The token transfer constitutes such an instruction. The securities themselves are not really tokenized: the definitive ledger remains offchain, the issuer retains discretion to reject the instruction, settlement may lag. The token is a carrier pigeon, not a security.

4. Control agreement tokens

The sophisticated cousin of the instruction model. The issuer has committed in advance to follow the token holder's instructions without further consent from the registered owner, via a "control agreement" under UCC § 8-106(c)(2). More bearer-like than the instruction model, and endorsed by the PEB. But the token still isn't the security; it represents contract rights regarding the security. Actual registered ownership may still lag.

5. Synthetic tokens

Perpetual futures, tokenized structured notes, security-based swaps. Not really "tokenization of securities" in any meaningful sense; it's the creation of new financial instruments providing synthetic exposure to a reference asset. The holder of a perp on AAPL doesn't own Apple shares. Useful, but a different project entirely.

There is also a soxtj category, what I've elsewhere called souvenir tokens, a form of 'slop tokenization' where the blockchain is nominally used as a ledger but no legal instrument makes the onchain state authoritative. The token reflects an offchain record but nothing gives it legal force. A receipt for a receipt.

The security token protocols vaguely assumed they were building for something like model 1, or at least that the token transfer was the legally operative event. They then built compliance machinery to gate that event. But the tokens they actually produce, as deployed in the real world, are almost always operating in model 3 (instruction tokens), model 4 (control agreements), or as souvenirs. Most sit somewhere between instruction and souvenir, and the protocols themselves don't know which.

Look at where the major implementations actually land. Superstate's USTB and USCC tokens are ERC-20s on Ethereum, but the fund's transfer agent (a traditional SEC-registered entity) maintains the authoritative record of ownership offchain. The onchain token is, at best, an instruction mechanism: when you transfer it, the transfer agent decides whether to honor the transfer on its books. ERC-3643's T-REX tokens, as deployed by Tokeny and its clients, operate in the same functional register: the compliance pipeline gates the onchain transfer, but the legal record of ownership typically lives with the issuer or its transfer agent, making the token a compliance-wrapped instruction or a compliance-wrapped souvenir. Securitize's DS Protocol is architecturally isomorphic: the compliance layer validates who can hold and transfer, but the authoritative holder records are maintained by Securitize the company, functioning as transfer agent. ERC-1400 adds partition labels that gesture toward per-tranche semantics, but the partitions carry no standardized metadata schema and the token still doesn't know what legal instrument it represents. Shallow self-knowledge that doesn't change the fundamental ontological position.

None of these tokens are model 1. None of them are the security. The compliance infrastructure they carry was engineered on the assumption that they are.

The disintermediation implications are clear. In every one of these implementations, a transfer agent, issuer, or platform operator remains the authoritative gatekeeper of the ownership record. The blockchain has not removed the intermediary. It has added a notification layer in front of the intermediary. The stockholder's legal position is no different than it would be without the blockchain: they still depend on Securitize, or Superstate's transfer agent, or the issuer's internal systems to recognize their ownership. The chain is doing nothing that matters. As I put it in the 5 Ways piece: you've rebuilt the old plumbing with shinier pipes. The securities are not really onchain. What's onchain is intermediary cosplay: the old system in a token costume.

The PEB Report and the Instruction Token Model

The clearest articulation of what most of these tokens actually do, as opposed to what the security token industry assumes they do, comes from an unlikely but authoritative source. The Permanent Editorial Board for the Uniform Commercial Code (the body responsible for monitoring and interpreting the UCC, jointly appointed by the American Law Institute and the Uniform Law Commission) has been circulating a draft report on the tokenization of securities transfers. The report, drafted by Chuck Mooney, Ed Smith, Andrea Tosato, and Steve Weise, among the most respected names in U.S. commercial law, addresses a question the security token industry has largely ignored: how do digital tokens fit into the existing statutory framework for transferring registered ownership of uncertificated securities under UCC Article 8?

The report is careful to distinguish several token functions. Its primary focus is on tokens as instruction mechanisms, where transfer of control of the token constitutes a notification to the issuer to register a change of ownership. But it also analyzes control agreement tokens, where the token's function is to bind the issuer to a control agreement under UCC § 8-106(c)(2), enabling perfection and priority of security interests without changing registered ownership. And the report explicitly reserves the possibility that the platform on which tokens are recorded could itself serve as the issuer's books and records of registered ownership, in which case the transfer of a token could effectively transfer registered ownership directly, without a separate instruction-and-registration step. The report takes no position on the merits of that architecture, but it acknowledges the design space.

That reserved possibility is worth flagging, because it is the only model in which the blockchain actually disintermediates anything. If the platform is the issuer's books and records, then the token transfer is the change in registered ownership, no separate transfer agent processing step needed. But if the platform is just a communication channel for instructions to a transfer agent, the intermediary remains, and the blockchain's role is limited to message delivery.

The instruction token model is the most revealing for present purposes, because it is what most deployed tokenization projects are actually doing, even if they don't describe it that way.

The PEB's treatment is explicit: the token (which it calls the "ABC Token" in its case studies) is not a security. It is a Controllable Electronic Record under UCC Article 12 whose transfer of control constitutes an "instruction", a notification communicated to the issuer directing that the transfer of the uncertificated security be registered. The token functions as the mechanism through which the registered owner exercises their right to instruct the issuer, but UCC Article 8, not control of the token as such, is the source of that right. The ABC Token has no other power or right linked to it.

Under this model, every transfer of the token is a message to the issuer: "register this person as the new owner." The issuer is obligated to comply, but only if the conditions specified in UCC § 8-401(a) are met, which include (among other things) that the instruction is "originated by an appropriate person" and "the issuer has no duty to inquire into adverse claims" or has discharged its duty. These are standards that the issuer evaluates. Not standards that a smart contract enforces against anonymous wallet addresses at the transfer layer.

Now look at what ERC-3643 actually does. When transfer(to, amount) is called, the token executes five sequential checks: the contract must not be paused; neither sender nor receiver can be frozen; the sender needs sufficient free balance; the receiver must be verified through the ONCHAINID identity registry; and all compliance modules must approve. Only then does the ERC-20 _transfer() execute.

This architecture makes sense only if the token transfer IS the change in ownership, if the _transfer() call is the settlement, the legal delivery, the moment at which title passes. But for most real-world deployments, that is what the token transfer is not. In most tokenized securities implementations, the authoritative record of ownership lives on a transfer agent's books, on Carta, in a law firm's files, or in the issuer's internal systems. The onchain state is a reflection, a notification layer, or at best a communication channel. The compliance infrastructure wrapped around the transfer is guarding a door that doesn't lead to the room it thinks it does.

Why Hardcoded Transfer Compliance Makes No Sense for Instruction Tokens

Take the instruction token case (model 3), the most legally rigorous non-ledger model and the one the PEB report's case studies focus on.

When a token is a mere instruction, the entire compliance question shifts downstream. The transfer agent or issuer receives the instruction and then decides whether to honor it. The issuer already has the full suite of tools it needs to enforce compliance at that point: it can refuse to register the transfer, it can condition registration on KYC/AML verification, it can enforce transfer restriction notations, it can apply Rule 144 holding period checks, it can verify accredited investor status, it can enforce rights of first refusal and co-sale rights. It does all of this in the ordinary course of administering its stock ledger. That is what transfer agents do. That is what issuers do when they self-administer. These are offchain or hybrid processes that have worked for decades.

And these processes are not manual. Modern transfer agent platforms (Computershare, EQ, Carta for private companies) are sophisticated automated systems. They maintain per-share databases tracking restriction types, acquisition dates, affiliate status, opinion letters on file from issuer's counsel, KYC/AML/FATCA clearances, stop-transfer orders, and the full corporate action history. Carta automatically tracks Rule 144 holding period dates and requires them before transactions can be processed. When a transfer instruction arrives at one of these systems, it is evaluated against all of this contextual data, much of it automatically. The compliance isn't a person reading a fax and making a gut call. It is an automated platform with rich, per-share data operating under the supervision of regulated professionals who bear legal accountability for the results.

That is why the onchain compliance layer is redundant in the instruction token model. The transfer agent's system already knows the holder's identity, their acquisition date, their affiliate status, the specific restrictions on their shares, the opinion letters on file, and the issuer's reporting status. ERC-3643's compliance modules know whether an address appears in a whitelist. The onchain layer is a thin, less-informed duplicate of the compliance check that the transfer agent's own platform is already running, with less data, less context, and no legal accountability for the output. Adding a CountryAllowModule on top of a system that already maintains per-holder jurisdiction data, investor qualification records, and risk-based compliance workflows is not automation. It is redundancy.

The instruction token doesn't need a seven-contract onchain compliance pipeline because the compliance happens when the issuer processes the instruction. The onchain pipeline is actually worse than the offchain process it replaces, for several reasons.

First, the onchain pipeline misidentifies who bears the compliance obligation. Securities don't have compliance obligations. People and entities do. Securities are allowed to trade peer to peer relatively freely; it is mostly that various types of intermediaries are subject to regulations in how they can trade them or facilitate trading in them. A broker-dealer has obligations under the Exchange Act and FINRA rules. A transfer agent has obligations under Exchange Act § 17A. An investment adviser has fiduciary duties. An issuer has obligations under Regulation D or Regulation S regarding who it sells to in the initial offering, and ongoing obligations regarding restriction notations and stop-transfer orders.

None of these obligations are obligations of the token. They are obligations of regulated persons and entities. Those persons and entities don't discharge their obligations by pointing to a canTransfer() function and saying "the smart contract approved it." They discharge their obligations by maintaining compliance programs that combine automated systems, supervisory judgment, documentation, and accountability. A compliance module that returns true or false based on deterministic inputs is not a compliance program. It is a boolean function masquerading as one. The real compliance program is the one the transfer agent is already running offchain, with richer data, broader context, and legal accountability attached to the output.

A basic principle of securities regulation is that a regulated entity cannot delegate its legal obligations to a piece of infrastructure and treat the delegation as compliance. A broker-dealer does not satisfy its AML obligations by subscribing to a screening vendor and blindly following the vendor's output; it must maintain its own independent judgment and supervisory procedures. A transfer agent does not satisfy its obligations under Exchange Act § 17A by deferring to a smart contract's canTransfer() response; it must independently evaluate whether the conditions for registering a transfer have been met. The compliance obligation is non-delegable. It follows the regulated person, not the infrastructure. An onchain compliance module is a tool the regulated entity might use as part of its compliance program, but it is not the compliance program itself, and deploying it does not relieve anyone of anything.

ERC-3643's agent architecture, where designated agents can freeze wallets, force transfers, pause the entire contract, and recover tokens, makes this visible. These are powers that a transfer agent or issuer might need to exercise. But they are wired into the token contract itself, as if the token were the transfer agent. The token is playing dress-up. It has assumed the role of a regulated intermediary without actually being one, without the legal obligations that attach to that role, and without the judgment, discretion, and accountability that the role requires. The architecture concentrates the same powers that traditional intermediaries hold (freeze, force transfer, pause, recover) in a set of admin keys, while stripping away the regulatory accountability, fiduciary duties, and supervisory oversight that constrain those powers when exercised by actual regulated entities. It is re-intermediation without the safeguards. Intermediary cosplay in the most literal sense.

These admin powers also destroy the property that makes a security "marketable" in the sense that matters for blockchain composability. For a tokenized security to function as DeFi collateral, the lender needs to know it can seize and liquidate the collateral without the issuer intervening. If the issuer retains a unilateral freeze, force transfer, or pause power at the contract level, the lender can never have exclusive control. A founder pledging tokenized shares through an ERC-3643 contract cannot grant a lending protocol the kind of exclusive security interest that collateral requires, because the issuer's admin keys can override the lender's position at any time. As critiques on the Ethereum Magicians forum observed, this renders the token "worthless from a bank compliance perspective" as collateral. The same problem extends to trading: a token that the issuer can freeze at will is not independently tradeable in the way that a bearer instrument or a self-custodied asset is. The god-mode admin powers that these protocols build in, ostensibly for compliance, make the tokens unsuitable for the composable, issuer-independent secondary market activity that was supposed to be blockchain's contribution to securities markets. You cannot have a truly marketable tokenized security if the issuer retains a kill switch over every transfer. Swen Werner (formerly Head of Digital Custody and Payments at State Street Digital) identified this exact problem in his broader critique of controlled systems masquerading as uncontrolled ones: the hidden layers of centralized control undermine the properties that the decentralized substrate is supposed to provide.

Securitize's DS Protocol is slightly more honest: its v4 implementation explicitly separates the Transfer Agent role from the Issuer role in its Trust Service, which mirrors the real-world separation. But the underlying architecture is the same: an ERC-20 balance model, a compliance check that gates every transfer, and an onchain identity registry. The token still doesn't know what it represents. The intermediary chain (issuer, transfer agent, compliance provider, identity registry operator) is no shorter than it was before tokenization. It may actually be longer, because now there is an additional layer of smart contract infrastructure to maintain, audit, and upgrade on top of the existing offchain compliance program that the regulated entity is still legally required to operate.

The disintermediation failure here is not incidental. It is structural. By encoding intermediary compliance workflows into the token itself, these protocols don't just fail to disintermediate; they make disintermediation architecturally impossible within their own systems. The compliance modules are designed around the assumption that an intermediary (the "agent") is always present. The identity registry assumes a centralized verifier. The forced-transfer and recovery mechanisms assume admin-key control. If you tried to remove the intermediary, if you tried to make the token self-sufficient, so that holders could transact peer to peer without a centralized compliance gatekeeper — the entire architecture would break, because it was designed from the ground up to require one.

Second, the onchain compliance pipeline assumes that transfer restriction is the primary modality of securities regulation. It is not. The private securities market (where most tokenized securities live) is primarily regulated through offering restrictions (who the issuer can sell to), holding period restrictions (Rule 144), and resale restrictions (conditions under which restricted securities can be resold without registration). These restrictions are conditions that the issuer or transfer agent evaluates and enforces as part of administering the ledger. They are not conditions that the token itself needs to check on every transfer, because whether a particular transfer satisfies Rule 144's conditions (adequate current public information, holding period, volume limitations, manner of sale, Form 144 filing) depends on facts and judgments that the protocols don't even attempt to encode.

Could you build onchain attestation mechanisms for Rule 144 conditions? In principle, yes. An oracle or issuer-controlled flag could attest to whether the adequate current public information requirement of Rule 144(c) is satisfied, whether the volume limitations of 144(e) have been observed, whether the manner-of-sale conditions of 144(f) are met. But the protocols didn't build any of this. ERC-3643's several built-in compliance modules include a CountryAllowModule, a MaxBalanceModule, and a lockup period module (which approximates 144(d)'s holding period in the crudest possible way). They include nothing for 144(c), nothing for 144(e), nothing for 144(f), nothing for the Form 144 filing requirement of 144(h). The gap between what these protocols encode and what Rule 144 actually requires is itself the indictment. They built the parts of compliance that are easy to express as boolean checks and ignored the parts that require substantive legal judgment, then marketed the result as "compliant securities."

And what the securities laws actually regulate is not the bilateral agreement between buyer and seller. They regulate public offerings of securities (Securities Act § 5), the activities of broker-dealers (Exchange Act § 15), the activities of transfer agents (Exchange Act § 17A), the activities of investment advisers (Advisers Act § 203), and so on. These are regulations on intermediaries and issuers, not on tokens. In the United States, securities trade peer to peer all the time without any intermediary validating the transaction. If I own restricted stock in a private company and I want to sell it to my neighbor, I can do that, subject to the transfer restrictions in the company's governing documents and the conditions of the applicable exemption from registration. The company (or its transfer agent) will need to evaluate whether to register the transfer on its books. But the trade itself, the agreement between me and my neighbor, doesn't require a compliance module to approve it.

Third, even setting aside the questions of who is obligated and what modality of regulation applies, the onchain pipeline is inflexible in a way that is incompatible with how compliance actually works. ERC-3643's modular compliance system ships with ten plugin modules: CountryAllowModule, CountryRestrictModule, MaxBalanceModule, SupplyLimitModule, and so on. These are rigid, deterministic rule checks. But real securities compliance isn't a checklist of deterministic rules. It is a risk-based, judgment-intensive process governed by principles, not bright lines. A transfer agent evaluating whether to register a transfer doesn't just check a boolean country-allow list. It considers the totality of the circumstances: the nature of the securities, the identity and sophistication of the parties, the applicable exemptions, whether the transfer might constitute a distribution, whether there are open stop-transfer orders, whether the transaction is consistent with the issuer's compliance program.

AML/CFT compliance in particular is a risk-based, judgment-driven regime. The BSA (31 U.S.C. § 5318(h)) requires covered financial institutions, including broker-dealers, to establish anti-money laundering programs with four minimum components: (A) internal policies, procedures, and controls; (B) a designated compliance officer; (C) an ongoing employee training program; and (D) an independent audit function. FinCEN's implementing regulations at 31 CFR § 1023.210 require broker-dealers specifically to maintain "appropriate risk-based procedures for conducting ongoing customer due diligence," including understanding the nature and purpose of customer relationships to develop a customer risk profile, and conducting ongoing monitoring to identify and report suspicious transactions. FINRA Rule 3310 mirrors this, requiring that each member firm's AML program be "reasonably designed to achieve and monitor" compliance with the BSA. The 2020 Anti-Money Laundering Act reinforced what was already clear in practice: these programs must be "effective, risk-based, and reasonably designed," enabling institutions to "focus their resources and attention in a manner consistent with their risk profiles."

The architecture of this regime is intentionally principles-based. The CDD requirements applicable to broker-dealers under 31 CFR § 1023.210 require "risk-based procedures," not deterministic rules. The FFIEC BSA/AML Examination Manual instructs examiners to assess whether a bank's CDD program is "commensurate with the bank's BSA/AML risk profile, with increased focus on higher risk customers." Institutions are expected to collect more information for higher-risk customers and may collect less for lower-risk ones, "as appropriate." The monitoring obligation is explicitly event-driven: institutions update customer information "as a result of normal monitoring," not on a mechanistic schedule. Suspicious activity reporting, the centerpiece of the BSA reporting system, requires institutions to file SARs when they detect "known or suspected" criminal violations, a standard that requires human judgment about what constitutes suspicious activity in context.

None of this can be expressed as a CountryRestrictModule. A hardcoded boolean function that returns true or false based on whether an address appears in an allowlist is the opposite of risk-based compliance. It is rule-based compliance, the approach that the BSA framework has spent decades moving away from, precisely because deterministic rules are easy to game and incapable of adapting to novel patterns of illicit activity. The security token protocols took the most sophisticated, judgment-intensive compliance regime in financial regulation and reduced it to a set of if-then conditions in a smart contract. That isn't compliance automation. It is compliance cosplay.

By hardcoding the compliance at the transfer layer, the protocol gives the false impression that compliance is being handled. It is not. It is being gestured at. The gesture comes at a real cost: gas expenses, composability constraints, a false sense of security, and the embedding of today's compliance assumptions into immutable (or at least difficult-to-upgrade) smart contract code.

The irony: the protocols that bill themselves as "compliance solutions for tokenized securities" are building a compliance apparatus for tokens that are not securities. They are building transfer restriction infrastructure for instruction tokens that could just as easily be restricted by the issuer refusing to honor the instruction. They are building identity verification pipelines for souvenir tokens whose entire legal significance derives from offchain records that don't care about the onchain identity registry. The compliance is real in the sense that code is executing. It is fictional in the sense that the code is not discharging anyone's actual legal obligations.

The Permissioned-Ledger Variant

Now turn to the other camp flagged in the introduction: the architects who concluded that the problem isn't the token but the execution environment itself.

The Canton Network, built on Digital Asset's DAML language, doesn't wrap a public-chain token in compliance infrastructure; it replaces the public chain entirely. In DAML, a transaction cannot even be constructed unless it is authorized by the correct parties at the language level. Unauthorized participants never see the transaction, cannot propose it, and cannot route it. The ledger records only authorized, bilateral contractual acts. This is presented as necessary to satisfy frameworks like SEC Regulation SCI, CFTC DCO Core Principles, and the CPMI-IOSCO Principles for Financial Market Infrastructures (PFMI). Canton has attracted serious institutional participants (DTCC, Broadridge, and as of this week Visa as a "Super Validator"), and the question of whether it is even a blockchain in any meaningful sense has become a live debate at events like Blockworks DAS. ZKsync co-founder Alex Gluchowski put the point bluntly this week in a series of posts:

His argument: Canton requires issuers to retain full administrative control, which means enforcement depends on the issuer's good faith rather than on code. "On Ethereum, enforcement is guaranteed by math and open-source code. Canton calls that a feature, but every investor on the other side of the trade should call it a risk."

The problem is that none of these frameworks actually require what Canton's architecture provides.

Reg SCI requires covered entities to maintain systems with adequate "capacity, integrity, resiliency, availability, and security." It requires policies and procedures to "detect and investigate potentially unauthorized access." The PFMI's Principle 17 (operational risk) requires FMIs to "identify the plausible sources of operational risk" and "mitigate their impact through use of appropriate systems, policies, procedures, and controls." Principle 18 (access and participation) requires "objective, risk-based, and publicly disclosed criteria for participation." The CFTC's implementation of the PFMI imposes analogous obligations on derivatives clearing organizations.

These are meaningful requirements. They mandate effective access controls, operational security, defined participation criteria, and the ability to demonstrate that every processed instruction was properly authorized. But they do not mandate that unauthorized attempts be structurally impossible at the protocol level. They require that unauthorized transactions cannot be processed, not that unauthorized inputs cannot enter the system at all. The distinction is between what regulatory frameworks call "preventative controls" (structurally excluding unauthorized actions) and "detective controls" (identifying and rejecting them). Both satisfy the regulatory obligation. Canton happens to implement the former, but the latter is equally compliant.

A traditional clearing system achieves authorization through network credentials and message filtering: only approved members have connectivity to the matching engine. Ethereum achieves it through runtime access control: anyone can submit a transaction, but the contract's require() check reverts unauthorized calls before any state change occurs. Both approaches prevent unauthorized state changes. Canton goes further by eliminating the concept of an unauthorized attempt entirely, but this is a design choice for system assurance, not a regulatory necessity.

The upshot is that Canton, like ERC-3643, sacrificed something real for something imaginary. The permissioned-ledger model gives up the properties that make public blockchains valuable (open verifiability, censorship resistance, composability, and genuine disintermediation) in exchange for a level of authorization assurance that regulators have never demanded. Where ERC-3643 re-intermediates at the token layer (agents with admin keys playing the role of transfer agents), Canton re-intermediates at the infrastructure layer (institutional nodes with permissioned access playing the role of CSDs). Neither architecture reduces the number of trusted third parties a stockholder must rely on. Both preserve the full intermediary chain and add a technology layer on top. Canton's sub-transaction privacy, bilateral contract states, and permissioned participant network are architecturally isomorphic to the existing post-trade infrastructure (DTCC, Euroclear, Clearstream) rebuilt in DAML rather than COBOL. The participants are the same institutions. The access model is the same gated membership. The bilateral opacity is the same need-to-know compartmentalization. Canton didn't disintermediate the post-trade stack; it reimplemented it on a different substrate. Gluchowski's deeper critique sharpens this: Canton's privacy and integrity model relies on a single mechanism (trusted operators segregating data between participants) with no cryptographic verification layer and no independent check. If a few operators in a validation domain are compromised, manipulated state propagates silently. By contrast, a public-chain architecture with ZK proofs provides layered defenses: the base chain verifies computation independently of any operator, and a compromised instance's blast radius is contained. "Cryptographic verification provides both [redundancy and containment]. Trust in operators provides neither."

And for corporate equity specifically, Canton's sub-transaction privacy forecloses one of the core benefits tokenization is supposed to deliver. DGCL §§ 219 and 220 grant stockholders the right to inspect the corporation's stock ledger and make copies. Section 220 provides that any stockholder may demand inspection "for any proper purpose," and Delaware courts have consistently enforced this right. A stockholder could still exercise that right against a Canton-based issuer through traditional channels; the privacy model doesn't make inspection impossible. But a public-chain architecture would make it automatic: the ledger is open, verifiable, and queryable without a demand letter, a court order, or a week of lag. Canton's privacy model, built to satisfy a regulatory requirement that doesn't exist in the form assumed, sacrifices the efficiency gain that would come from satisfying a corporate law requirement that does.

The obvious objection to a public-chain stock ledger is privacy. Corporate cap tables contain sensitive information: who owns how much, at what price, under what restrictions. Putting that on a public chain in plaintext is a nonstarter for most issuers and investors. This is a real concern, and one that Canton's privacy model addresses (at the cost of everything else). But it is an engineering problem with known solutions, not a reason to abandon the public-chain model. In the near term, personally identifiable information on ledger entries can be encrypted with issuer-controlled view keys, so that the ledger is publicly verifiable in structure (you can confirm that entries exist, that the protocol rules are being followed, that the total share count is correct) while the identity fields are readable only by authorized parties. Longer term, the architecture points toward each issuer operating its own ZK rollup environment with state-level access controls (ZKsync's Prividium is the most developed version of this architecture, already in use by Deutsche Bank and several US regional banks), where the full ledger data lives in a privacy-preserving execution layer that settles to a public chain. The stockholder inspection right is satisfied because authorized parties (the issuer, its counsel, stockholders exercising § 220 rights) can access the underlying data, while the public chain provides the settlement finality and verifiability guarantees that make the ledger authoritative. The point is that privacy and public-chain settlement are not in tension if you put the privacy at the right layer. Canton puts it at the wrong layer, sacrificing settlement transparency to get transaction privacy, when the reverse architecture (transparent settlement, encrypted state) preserves both properties.

The Common Thread

The common thread across all of these architectures (ERC-3643's compliance modules, ERC-1400's partition system, Securitize's Trust Service, Canton's semantic authorization model) is that they started from assumptions about what regulation demands, built engineering to satisfy those assumptions, and never checked whether the assumptions were correct. The result is a generation of tokenization infrastructure solving imagined problems while ignoring real ones.

But there is a deeper thread, and it explains why the engineering went wrong in such a consistent direction: every one of these projects treated intermediation as given. They assumed securities would continue to be administered by transfer agents, gated by compliance providers, custodied by intermediaries, and traded through permissioned channels, and that the blockchain's role was to make that existing intermediary chain slightly more efficient, transparent, or interoperable. This assumption was never stated explicitly, but it is visible in every architectural choice: ERC-3643's agent-key system, Securitize's offchain transfer agent, Superstate's traditional fund administrator, Canton's institutional node operators. The blockchain is a coordination layer for incumbents, not a disintermediation technology for end users.

That assumption led directly to the false premises. If intermediaries are given, then the token doesn't need to be constitutive: the intermediary will handle the real ownership record. If intermediaries are given, then compliance can be encoded in the token, because the intermediary's compliance program is supplemented, not replaced. If intermediaries are given, then the blockchain doesn't need to be public, because the participants are known institutions, not pseudonymous individuals exercising self-custodied ownership rights.

Every false premise in this article flows from treating intermediation as a design constraint rather than as the problem to be solved. And the cost is not merely analytical. Blockchains are, at their core, settlement layers: systems that create finality. That's what gives them their unique economic properties: when the blockchain says a state transition happened, it happened. The entire DeFi ecosystem rests on this. When the security token protocols reduced the chain to a notification layer for an offchain intermediary (which is what models 3, 4, and the souvenir approach all do) they threw away the one property that justifies using a blockchain at all. Why would anyone build DeFi protocols, governance systems, or automated corporate actions on top of a layer that isn't authoritative? The onchain state becomes a suggestion, not a fact. And even if the state were authoritative, the admin powers baked into these protocols (freeze, force transfer, pause, recover) mean that no lending protocol or trading counterparty can rely on the token's behavior being predictable. A security that the issuer can freeze at will is not composable, not pledgeable, and not independently tradeable. The god-mode admin architecture doesn't just re-intermediate; it actively destroys the marketability that tokenization was supposed to create. This is why existing tokenized securities have generated so little meaningful ecosystem activity: their tokens either don't mean anything at the definitive legal layer, or they carry admin override risks that make them unusable as DeFi primitives. There is nothing credible to compose with.

The imagined problem: "tokens need to be made compliant."

The real problem: "what would it mean for a token to actually be a security, and for the holder to actually own it, directly, without an intermediary's permission?"

Those are different questions. The first takes the token as given and asks how to constrain it. The second asks what architecture would make the token constitutive of the legal relationship it purports to represent, and what that constitutive relationship would mean for the intermediary chain. The entire security token industry answered the first question. Almost nobody asked the second.

A reasonable objection: maybe the current approaches are a pragmatic starting point. Building a thin veneer of blockchain functionality on top of legacy transfer agent systems is the fastest go-to-market, and the architecture can be made more robust over time. Ship the instruction token now, make the chain constitutive later. Progressive decentralization applied to securities infrastructure.

The problem is that progressive decentralization, as a strategy, has a poor track record. The centralized dependencies tend to become structurally embedded. The intermediary's offchain database becomes the system of record that everyone relies on, the admin keys become operationally necessary, the compliance modules become contractual obligations to institutional partners, and the cost of migrating away from any of them exceeds the cost of just keeping them. The late Nikolai Mushegian, architect of MakerDAO's original DAI system, warned against this explicitly in his principles for the Rico protocol: teams should avoid playing in "decentralization theaters," because every point of centralization, including interfaces and repositories, can be hacked; true decentralization must allow the protocol's mechanics to protect themselves. The ERC-3643 agent architecture is a concrete illustration. The Owner and Agent roles cannot be constrained, timelocked, or governance-minimized without abandoning the standard's own enforcement model. There is no upgrade path from intermediary cosplay to real tokenization within this architecture. The centralized control isn't scaffolding that can be removed later; it is the structure itself.

What It Means to Really Put Securities Onchain

The only context in which onchain compliance infrastructure does structural work, where it isn't redundant to the issuer's own compliance processes, is when the token IS the security. When the onchain state is the authoritative legal record. When the transfer function is the settlement. When there is no downstream issuer processing the instruction and applying its own compliance checks, because the smart contract system is the issuer's ledger and the transfer function is the registration of the transfer. This is what it means to really put securities onchain: not to put a notification layer on a blockchain, but to make the blockchain the stock ledger.

This is model 1: the chain-as-ledger approach. It requires a completely different architecture than anything ERC-3643, ERC-1400, ERC-7943, or Canton provides. It also requires engaging directly with the design space the PEB report reserved but did not explore: the possibility that the platform on which tokens are recorded could itself serve as the issuer's books and records of registered ownership.

At MetaLeX, this is what we've built with the CyberCorps protocol. The architecture begins from corporate law, specifically the Delaware General Corporation Law, and builds outward to the token, rather than beginning from the token and trying to retrofit legal meaning.

The corporation's bylaws and certificate of incorporation explicitly designate the onchain system as the official stock ledger under DGCL § 224. The token doesn't merely represent a stock ledger entry; it IS the stock ledger entry. Holding it makes you the stockholder of record. The governing legal instruments fuse the onchain state to the legal reality, so that the smart contract system is performing real legal work, not mirroring an offchain record. CyberCorps takes the path the PEB report left open and builds the legal and technical infrastructure to make it work.

Each Stock Ledger Entry Token (ERC-721) is an onchain record carrying the information Delaware corporate law and federal securities regulation require to be recorded or associated with equity ownership: the name of the registered holder, the class and series of shares, the number of shares, restriction notations per DGCL § 202, acquisition dates (for Rule 144 holding period tracking), officer authorizations, and links to the governing documents. The token knows what entity issued it, what rights and restrictions attach to it, and what legal framework governs it. ERC-3643 tokens carry none of this. They are mapping(address => uint256), a number associated with a wallet address, semantically indistinguishable from a fungible balance in any other ERC-20. The compliance layer validates who can hold and transfer, but is silent on what they hold.

Because the CyberCorps token is the legal record, transfer restrictions encoded in the smart contract are doing real work. They are not redundant to an offchain compliance process, because there is no separate offchain ledger serving as the system of record. The onchain restriction IS the DGCL § 202 restriction. The issuer's refusal to register a noncompliant transfer is implemented by the smart contract's transfer hook rejecting the transaction. Because the smart contract IS the stock ledger, and rejecting the transaction IS the issuer's refusal to register the transfer. These are the same act.

The bylaws explicitly address the ontological question that the ERC standards leave unresolved. They define "Instruction Tokens," "Stock Ledger Entry Tokens," "Scrip Tokens," and "Control Agreement Tokens" as distinct categories with distinct legal significance. They state that "no change in record ownership of a Tokenized Share shall be deemed to occur solely by virtue of any transfer, assignment or other disposition of any Blockchain Token among Blockchain System addresses," explicitly acknowledging that blockchain state transitions do not carry intrinsic legal significance, and then supplying the legal infrastructure that creates that significance for specific token categories in specific ways. Changes in registered ownership happen by mutating the entry token's onchain metadata (updating the registered holder field, the restriction notations, the endorsement history) not by transferring the NFT between wallets. This distinction between moving an NFT and changing who owns shares is what gives the ledger model its resilience to hacks, mistakes, and unauthorized transfers: a thief who steals an entry token has moved an NFT, but the metadata still records someone else as the registered owner. The architectural design itself is the primary safeguard. This ontological precision, absent from every ERC standard and every competing protocol, is the foundation on which the rest of the architecture rests.

CyberCorps handles the compliance problem correctly in the same way. Transfer restrictions are per-ledger-entry (matching DGCL § 202's requirement that restrictions on uncertificated shares be contained in the notice required by § 151(f)), not global across all tokens. A holder can have 500 restricted shares and 500 freely tradeable shares, represented by different entry tokens with different restriction metadata, something impossible in ERC-3643's global compliance model, where a single compliance module applies uniformly to every token in the contract.

None of this is achievable within the instruction token model, regardless of how many compliance modules you bolt onto it. You cannot disintermediate a system that is, by construction, a message to an intermediary.

Here is where disintermediation becomes real. In the CyberCorps model, the stockholder holds their own ledger entry. Not a pointer to a ledger entry maintained by a transfer agent. Not an instruction token that asks an intermediary's permission to register a change. The actual entry itself, in their own wallet, with its own metadata, on a public chain anyone can verify. No transfer agent stands between the stockholder and their ownership record, because the smart contract system is the stock ledger, and the stockholder's custody of the entry token is their registration as the owner. The issuer retains the governance powers DGCL requires (the ability to enforce transfer restrictions, conduct corporate actions, maintain stockholder records), but those powers are exercised through the same onchain system, not through a separate offchain intermediary that the blockchain mirrors or notifies. The issuer self-administers its stock ledger through the protocol. Transfers between stockholders, subject to the applicable restrictions, settle atomically onchain, peer to peer, without an intermediary evaluating and approving each one after the fact.

Really putting securities onchain looks like this. The blockchain doing something that matters: not replicating an intermediary's function in a less capable medium, but eliminating the need for the intermediary by making the onchain state legally authoritative. Every other tokenization architecture, whether it wraps the token in compliance modules or replaces the chain with a bespoke VM, is intermediary cosplay: it preserves the intermediary chain and adds cost. CyberCorps shortens the chain.

This requires that MetaLeX itself not become the new intermediary. The protocol's smart contracts are upgradeable, but through an opt-in co-approval model: MetaLeX Labs can publish new contract implementations, but each issuer (each cyberCORP) decides whether and when to adopt them. No unilateral pushes, no forced migrations. An issuer can stay on its original contracts indefinitely. This keeps MetaLeX in the role of protocol developer and steward rather than a securities intermediary like a transfer agent or broker-dealer, which matters both for regulatory classification and for the trust model. If the protocol operator could unilaterally modify the stock ledger contracts, it would effectively be a transfer agent with admin keys, and we'd have recreated the intermediary dependency the architecture is designed to eliminate.

For DeFi composability, we use cyberSCRIPs, fungible ERC-20 tokens that can be minted against underlying Stock Ledger Entry Tokens through onchain scripification logic. Shares remain registered to the holder on the authoritative ERC-721 ledger, while a fungible representation circulates for liquidity purposes. The critical distinction from other tokenized securities: cyberSCRIPs are themselves securities, not mere wrappers or derivatives. They are securities in scrip form, with limited and contingent rights as specified in their terms of service, but their robustness as securities comes from something no other ERC-20 security token has: an intrinsic, auditable, in-protocol tieback to definitive registered ownership positions on the stock ledger. Every circulating cyberSCRIP traces back, through the protocol's own conversion logic, to a specific entry on the authoritative ledger. This is what makes them real tokenized securities rather than the compliance-wrapped instruction tokens or souvenirs that other protocols produce. The ontological clarity runs both ways: the entry token IS the ledger record; the scrip IS a security in scrip form; and the relationship between them is onchain, verifiable, and deterministic. ERC-3643 tokens have none of this layered precision. They are undifferentiated ERC-20 balances with no tieback to any authoritative ownership record, which is why wrapping them in compliance modules doesn't make them securities.

This architecture also directly solves the marketability problem that admin powers create in every other tokenization protocol. Because the cyberSCRIP is a distinct instrument from the underlying entry token, the issuer's governance powers over the stock ledger (which DGCL requires and which the entry token layer preserves) do not have to extend to the fungible trading layer. The cyberSCRIP contract includes irreversible disable toggles: the issuer can permanently and provably renounce specific admin powers (freeze, force transfer, blocklist) over the scrip, and once renounced, those powers cannot be restored by any party, including MetaLeX. This is a credible, onchain commitment that no offchain system can override. A stockholder can scripify their shares, deposit the resulting cyberSCRIPs into a lending protocol as collateral, and the lender obtains token-control of a fungible ERC-20 without the issuer's admin keys creating an override risk. The lender's security interest is real because no one can freeze or force-transfer the collateral out from under them. Compare this with ERC-3643, where the agent architecture means the issuer can freeze or recover the token at any time, making it unsuitable as DeFi collateral regardless of what the compliance modules say. The entry/scrip architecture is not a UX convenience; it is a legal separation that makes the trading layer genuinely independent from the issuer's governance layer, giving the security the measure of marketability that DeFi composability requires.

The protocol accommodates multiple legal theories at the scrip layer. The issuer's board can designate cyberSCRIPs to serve as instruction tokens (model 3, where transfer constitutes an instruction to the issuer), as control agreement tokens (model 4, where transfer assigns rights under a control agreement), or as legally inert representations for issuers operating in more intermediated or conservative contexts. The native, default design pattern is scrip as an onchain-verifiable extension of the ledger model, where the blockchain remains the settlement layer even for fungible tokens. But the architecture doesn't force a single legal theory on every issuer: it lets each issuer choose the model that fits its regulatory posture, while maintaining the chain-as-ledger foundation at the entry token level. The relationship between scrip and the underlying ledger entries is itself onchain, verifiable, and deterministic, a different trust model from one where an ERC-20 ties back to a transfer agent's offchain database through opaque API calls.

The SEC's January 2026 Joint Staff Statement on Tokenized Securities is the regulatory backdrop that makes this architectural distinction consequential. The statement confirms that tokenization doesn't alter the legal status of a security, that securities, however represented, remain securities, and economic reality trumps labels. This means that an ERC-3643 token carrying economic rights without stockholder governance is not equity regardless of its compliance features. It means that an instruction token with a seven-contract compliance pipeline is still just an instruction token. And it means that a properly structured Stock Ledger Entry Token, with officer authorizations, restriction notations, series terms, and endorsement history, issued from an onchain entity, governed by DGCL-compliant bylaws, could constitute the actual stock ledger entry under Delaware law.

Conclusion

The corrective is not to build a better compliance module. It is to ask a different question.

Not "how do we make this token compliant?" but "what legal architecture would make the onchain state authoritative, and what would that mean for the intermediary chain?"

The answer requires starting from corporate law, not token engineering. It requires bylaws that designate the onchain system as the authoritative record. It requires tokens that carry their own legal metadata: restriction notations, series terms, acquisition dates, officer authorizations. It requires an architecture where the compliance infrastructure is doing structural work, enforcing the issuer's actual transfer restrictions on the actual stock ledger, rather than performing compliance theater on a notification channel. And it requires the intellectual honesty to admit that a token which doesn't know what it is cannot be made compliant by wrapping it in infrastructure that doesn't know what it's protecting.

The security token industry built an answer to the wrong question. The right question was always about ontology, about what the token is, not what rules it follows. Get the ontology right and the compliance architecture follows naturally. Get it wrong and no amount of compliance engineering will close the gap. Get the ontology right and the blockchain is doing real work: the stockholder holds their own ledger entry, the ownership record is publicly verifiable, the intermediary chain is shorter than it was before. Get it wrong and the blockchain is a notification layer for an intermediary that didn't need a notification layer.

The stakes are higher than architectural taste. The reason anyone cares about putting securities on a blockchain is the possibility of a system where holders have direct, self-custodied ownership of legally authoritative records, where transfers settle peer to peer without intermediary processing, where the stock ledger is open and verifiable rather than locked in a proprietary database, and where the full lifecycle of a security (issuance, transfer, corporate actions, governance, restriction enforcement) runs through programmable infrastructure rather than manual administration. That system cannot be built on top of instruction tokens, regardless of how sophisticated the compliance wrappers become. It requires the chain-as-ledger model: tokens that are the legal record, on a chain that is the ledger, governed by instruments that fuse the two together.

It's time to stop building intermediary cosplay and actually put securities onchain.