RWA+: Extending the RWA Framework Beyond the Wrapper

Ivan Kan — Fri, 28 Aug 2026 23:34:02 +0000

Real-world asset tokenization, RWA for short, has become one of the most overused and under-defined terms in crypto. Ask ten people what makes something an RWA project, and you will get ten different answers, most of which describe a token that references an off-chain asset rather than one that constitutes it. I think that gap deserves its own name, which is why I have been using the term RWA+.

The distinction is simple to state and harder to build. A standard RWA token wraps an existing asset, gold in a vault, a bond held by a custodian, shares held in a brokerage account, and issues a claim on it. RWA+ describes something structurally different: native issuance, where the token is authorized and created as the instrument itself, not as a reference to one sitting somewhere else. There is no wrapper to unwind because there was never anything to wrap. The token was born as the asset, not minted afterward as a pointer to it.

Why does the plus sign matter beyond branding? Because it forces a different set of engineering and legal questions from day one. A wrapped RWA token's engineering problem is largely custody integration and redemption logic: how do you keep the token's supply and metadata in sync with whatever sits in the custodian's vault or account, and how do you build a clean redemption path back to that underlying position. It is a well-understood problem with well-understood tooling, oracle feeds, custodian APIs, attestation services, and most teams building in this category are essentially assembling variations on the same architecture.

An RWA+ token's engineering problem is building a ledger that a regulator, a transfer agent, and an issuer are all willing to treat as the actual record of ownership, with enforceable rights attached directly to the on-chain instrument. That is a fundamentally harder problem. You are not integrating with an existing system of record, you are building the system of record, which means your contract needs to correctly implement cap table logic, corporate actions, transfer restrictions tied to investor eligibility, and administrative functions that a regulated party can use to make corrections when needed, all while maintaining an audit trail that would hold up under regulatory examination.

Conflating these two categories does a disservice to teams doing the harder work. If you are evaluating a project's technical claims, one useful diagnostic question is this: if the custodian or off-chain data source this project depends on disappeared tomorrow, does the token still represent something enforceable, or does it become an orphaned reference to an asset no one can trace anymore? For a wrapped token, that dependency is real and often underappreciated. For a genuinely native RWA+ instrument, there should be no equivalent single point of failure, because the token was never dependent on an external custodial relationship in the first place.

I do not think RWA+ needs to replace the broader RWA category, and there are legitimate reasons a team might choose the wrapped approach, particularly for asset classes that genuinely cannot be re-originated on-chain, like physical commodities that exist independently of any blockchain and always will. Wrapped structures have legitimate uses and will likely coexist with native issuance for a long time. But the industry needs a shared vocabulary for the difference between "a token that points at an asset" and "a token that is the asset," because right now those two very different products, with very different engineering requirements and very different failure modes, are being marketed under the same three letters, and both builders and buyers deserve to know which one they are actually looking at.

The Entitlement Problem: Why DTCC's Model Doesn't Map Cleanly to Tokens

Ivan Kan — Fri, 28 Aug 2026 23:32:34 +0000

Most developers building in the tokenization space have never had to think about DTCC's entitlement model, and that is a gap worth closing before writing another line of smart contract code for a securities product.

In traditional US equity markets, when you "own" a share through a brokerage account, you typically do not hold a direct legal claim on the issuer. You hold an entitlement, a beneficial interest recorded by your broker, which in turn holds an omnibus position at a clearing entity, which in turn is recorded against the issuer's actual shareholder registry, maintained separately by a transfer agent. Ownership is a chain of entitlements, not a single direct record. This system exists for good reasons around settlement efficiency, letting the clearing entity net enormous transaction volumes without settling every individual trade against the issuer's registry in real time, but it also means the "real" record of who owns what sits several layers away from the end investor.

Now consider what happens when a team tries to tokenize an equity position without accounting for this. A token representing beneficial entitlement through a broker is not the same engineering problem as a token representing direct issuer-level ownership. The first requires reconciliation logic against an off-chain entitlement chain that can change independently of the token, meaning your contract needs some mechanism, whether an oracle, an API integration, or manual updates, to keep the on-chain representation synchronized with an off-chain source of truth that you do not control. The second requires the token itself to be the authoritative record, which means the smart contract has to handle cap table logic, transfer restrictions, and shareholder rights natively, not as a wrapper around something else.

This is where a lot of tokenization projects quietly under-scope their own complexity. It is straightforward to mint a token that references an off-chain position, essentially building a notification and transfer layer on top of a system of record that lives elsewhere. It is a fundamentally different engineering task to build a chain where the token is the entitlement, full stop, with no off-chain reconciliation required. Think about what that actually demands: your contract logic needs to enforce transfer restrictions that would traditionally be enforced by a broker or transfer agent reviewing each transaction manually, things like accreditation checks, lockup periods, and jurisdictional gating, all without a human in the loop for routine transfers.

The second approach removes an entire class of settlement risk, since there is no separate off-chain record that can drift out of sync with the token, but it requires the ledger to be trusted as the actual system of record by regulators, transfer agents, and issuers alike, which is a much higher bar than most projects currently clear. Getting there typically means partnering with, or becoming, a registered transfer agent whose legal function is to stand behind that record, because a smart contract alone, however well-audited, is not a legal person that a court or regulator can hold accountable.
A few practical implications for anyone architecting this kind of system. First, build your access control and administrative override logic assuming there will eventually be a need for corrections, whether due to a disputed transfer, a required regulatory action, or a corporate event like a preferred conversion, since a purely immutable system cannot accommodate the kinds of corrections that transfer agent regulation has always anticipated. Second, design your compliance gating at the contract level rather than the application layer, since application-layer gating can be bypassed by anyone interacting with the contract directly, undermining the entire point of building a compliant system.

If you are architecting tokenized securities infrastructure, the DTCC entitlement model is worth studying closely, not because you should replicate it, but because understanding exactly what problem it solves for traditional markets will tell you which parts of it your token architecture actually needs to reproduce, and which parts native issuance lets you skip entirely. The teams that skip this step tend to build something that looks like a solution to tokenization until it meets its first genuinely hard edge case, at which point the gap between "references an off-chain position" and "is the actual record" becomes very apparent, very quickly.

DEV Community: Ivan Kan

RWA+: Extending the RWA Framework Beyond the Wrapper

The Entitlement Problem: Why DTCC's Model Doesn't Map Cleanly to Tokens