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.
Top comments (0)