
Here’s What That Means for Institutional Tokenization.
ERC-7943: uRWA - Universal Real World Asset — authored by Brickken co-founder Dario Lo Buglio — has reached Final status in the Ethereum standards process. Adopters can build against it with the guarantee that it will not change. Most enterprises and infrastructure teams hold off on implementing a token standard until it reaches Final status, precisely because earlier-stage proposals can still be rejected or substantially altered. ERC-7943 has crossed that threshold and is now listed as an official standard.
Tokenization of real-world assets has spent the last years scaling without a shared foundation. Every platform built its own compliance logic. Every issuer forked existing token standards to bolt on transfer restrictions, allowlists, and enforcement actions. The result was predictable: fragmented integrations, inconsistent compliance models, and infrastructure that didn’t talk to each other across platforms.
It introduces a universal, minimal interface for compliant tokenization of real-world assets: a common ground that wallets, custodians, exchanges, DeFi protocols, and issuers can integrate against without locking into any one vendor’s compliance stack.
This article explains what the standard does, how it works at a technical level, and why it matters for institutions building or integrating tokenized asset infrastructure.

Existing token standards — ERC-20, ERC-721, ERC-1155 — were not designed with regulated assets in mind. They define how tokens move and act, but they don’t address the operational realities of real-world assets: eligibility checks, jurisdiction-specific restrictions, frozen balances, forced transfers under legal authority, and sanctions screening.
To work around this, many tokenization platforms have built their own version of these controls. Some encode KYC into the token contract itself. Others maintain off-chain registries that gate transfers. Some hard-code jurisdictional logic into forks; others abstract it into permissioned modules. None of these implementations are interoperable.
For institutions, this fragmentation creates four distinct problems:
The market has been waiting for a real standard that solves these problems without prescribing how compliance must work because compliance varies by jurisdiction, asset class, and issuer mandate. And as we’ll see next, the previous attempts at this haven’t closed the gap.
A reasonable reader will ask: hasn’t this been addressed already? There are existing frameworks that claim to handle compliant tokenization, vendor-published specifications, platform-native protocols or branded “security token standards” promoted by individual companies.
The issue is that most of them are not standards in any meaningful sense. They are proprietary frameworks, often controlled by a single company or either way having a centralized governance and for this a biased intellectual direction. Open source doesn’t always mean open standards in this context. An open source code with a centralized governance doesn’t give you the ability to influence the direction of the code.
For institutions, the implications are strategic, not just technical. Committing tokenization infrastructure to a vendor-controlled “standard” means the roadmap of that infrastructure is downstream of a single company’s commercial priorities. If that company gets acquired, pivots its product strategy, deprecates a feature, raises prices, or simply slows down, every issuer built on top of it is exposed. Regulators, auditors, and risk committees notice these dependencies and increasingly ask about them.
The result has been predictable: slower institutional adoption. Decision-makers responsible for significant mandates are hesitant to commit core infrastructure to a “standard” controlled by a single commercial entity or a single private vendor. They may find it difficult to justify that dependency to boards, regulators, or limited partners. This vendor-controlled model has slowed the development of shared infrastructure across the RWA market back from the velocity its underlying demand would otherwise produce.
It has also fragmented the ecosystem in a deeper way than incompatible code. When every major platform publishes its own “standard,” none of them become the standard. Wallets, custodians, and exchanges face an impossible choice about which proprietary framework to support so most support none of them well, and the network effects that should accelerate adoption never materialize.
ERC-7943 is not a reaction against any one competitor. It is a response to a broader issue: the over-consolidation of infrastructure under models that reduce optionality for builders. A healthy ecosystem needs standards that can be implemented independently, interpreted flexibly, and future proof — the only way to support diverse compliance logic, multiple identity models, and the regulatory heterogeneity of a global market.
ERC-7943 is structurally different because of how it was built. It was developed through the public EIP process with active input from the community, builders, and tokenization teams working on real implementation challenges. Its value is not that it sits outside the Ethereum standards process, but that it reflects an open, collaborative effort to define compliance infrastructure that others can implement, test, and extend.
That is what an open standard actually means, and it is what institutional tokenization has been missing.
“ERC-7943 doesn’t tell you how to comply. It gives you the tools to make compliance modular, interoperable, and programmable, without locking you into anyone’s system.”
— Dario Lo Buglio, ERC-7943 author
ERC-7943 defines a universal, minimal interface for compliance checks, transfer controls, and enforcement actions on tokenized real-world assets. It does not define a compliance model. It does not require a specific identity provider. It does not mandate jurisdictional logic.
What it does is far more useful: it gives every integrator ( wallets, custodians, exchanges, DeFi protocols, issuance platforms… ) a consistent, predictable way to ask the token whether a given action is permitted, and to act on the answer.
The design rests on three principles:
In other words: ERC-7943 doesn’t try to define how tokenization should work. It defines the shared interface that lets every implementation interoperate.
That definition emerged through public process. The standard was shaped over multiple cycles of feedback on Ethereum Magicians and within an open working group, surfacing edge cases and integration constraints from across the RWA ecosystem before reaching Final status. Standards developed without that kind of validation tend to become too opinionated, too narrowly applicable, or not future-proof. ERC-7943 was built specifically to avoid those failure modes.
The architecture separates concerns into three layers, each owned by a different part of the stack:
1. Integrators (apps, wallets, custodians, exchanges, DeFi protocols). They call a small, predictable set of functions to check eligibility and transfer permissions before executing or facilitating a transaction.
2. The token contract (ERC-7943 layer, on top of ERC-20/721/1155). It exposes the standardized interface — canTransact, canSend, canReceive, getFrozenTokens, setFrozenTokens, forcedTransfer — and emits consistent signals through standardized events and errors.
3. Policy and identity (agnostic). Issuers bring their own compliance stack: KYC/KYB providers, jurisdiction rules, sanctions screening, internal policy. None of this is standardized. The token consults whatever policy stack the issuer has chosen, and surfaces the result through the standard interface.
The result: integrate once, reuse everywhere. A wallet that supports ERC-7943 can interact correctly with any compliant token built on the standard, regardless of which compliance vendor the issuer uses underneath.
The standard, reference implementations, and supporting documentation are public:
For teams evaluating integration, the docs include the full interface specification across ERC-20, ERC-721, and ERC-1155 variants, integration guidance for wallets, custodians, and DeFi protocols, and reference patterns for connecting the standard to common compliance stacks.
A standard is only as useful as the ecosystem that adopts it. ERC-7943 launched with a coalition of established Web3 and fintech companies committed to interoperable, institution-ready RWA tokenization:
Backers and contributors: Bit2me, Brickken, Casper Network, CMTA Swiss, Compellio, Dekalabs, DigiShares, Forte Protocol, FullyTokenized, Propchain, RealEstate.Exchange, Stobox, and Zoth.
Security and audit partners: Hacken and QuillAudits.
The coalition spans the full RWA stack from issuance platforms, infrastructure providers, exchanges to marketplaces, identity, compliance vendors and audit firms. That is what really matters: a token standard adopted only by issuers, or only by infrastructure providers, doesn’t deliver interoperability. ERC-7943 is positioned across the value chain because real-world adoption depends on every layer aligning on the same interface.
For institutions and developers building on tokenized infrastructure, the practical implications are concrete:
Lower integration cost. A wallet, custodian, or DeFi protocol that adds support for ERC-7943 can interoperate with any compliant token implementation, regardless of the underlying compliance vendor.
Reduced vendor lock-in. Issuers can change their compliance stack, identity provider, jurisdiction logic or policy engine, without breaking integrations, because the integration surface is standardized at the token level.
Cleaner regulatory conversations. Legal and compliance teams have a documented, auditable interface to point to when explaining what a tokenized asset can and cannot do at the protocol level.
Composability with DeFi. Because ERC-7943 builds on ERC-20/721/1155, compliant tokens can plug into existing DeFi infrastructure where it makes sense without abandoning the controls institutions require.
In Dario’s words:
“We had struggled to find a framework that could meet both our regulatory and composability needs, which is why we built ERC-7943. Its modular structure made integration reliable, and the shared community support was a proof of that.
— Dario Lo Buglio, ERC-7943 author and Brickken co-founder
The standard is final, but the work isn’t. The roadmap includes a public implementation challenge, a roundtable series, hackathons, and shared showcase events designed to expand adoption and refine the standard against real-world deployments. Documentation, demo repositories, and community channels are open for any team building on or integrating with ERC-7943.
For institutions: this is the moment to evaluate whether your tokenization stack should be aligned to the standard.
For developers: the interface is small enough to integrate in days, not quarters.
The era of every platform inventing its own compliance primitives is ending. ERC-7943 is the shared foundation that makes institutional RWA tokenization composable, portable, and auditable across the industry, without forcing any single compliance model on anyone.