What Does ERC-7943 Standardise for RWA Tokenization?
ERC-7943, the Universal Real World Asset (uRWA) interface, is an Ethereum standard defining a minimal, vendor-neutral interface for compliant tokenization of real-world assets. It reached Final status in May 2026, freezing its interface, error definitions, event signatures and behavioural requirements for production use across Ethereum and EVM-compatible networks. The standard fixes four compliance primitives — canSend and canReceive for account eligibility, canTransfer for transfer authorisation, and forcedTransfer for enforcement — alongside a freezing mechanism, across three interfaces covering fungible, non-fungible and multi-token assets. What it deliberately does not specify is how any of those checks decide, binding no implementer to a particular identity provider or jurisdictional framework. This guide covers what the interface requires, why the separation of concerns matters, and what standardisation does and does not deliver.
TL;DR — Key Takeaways
- ✓Status: Final since May 2026. Interface, errors, events and behavioural requirements are frozen and available for production adoption on Ethereum and EVM chains.
- ✓The Four Primitives: canSend and canReceive (account eligibility), canTransfer (transfer authorisation), forcedTransfer (enforcement) — plus setFrozenTokens and getFrozenTokens.
- ✓The Mandated Separation: Account eligibility is separate from transfer authorisation, so an account can be blocked from receiving while still permitted to send. Losing eligibility must not trap a holder.
- ✓The Deliberate Silence: The standard says nothing about how checks decide, and binds no one to an identity provider or jurisdiction. It standardises the questions, not the answers.
- ✓What It Buys: Integration surface. One integration covers every conforming token. It does not make an issuer compliant — that remains a legal problem the interface cannot solve.
A Standard That Standardises the Questions
ERC-7943 defines a minimal, vendor-neutral interface for compliant tokenization of real-world assets, covering transfer validation, asset freezing, forced transfers and enforcement actions. It reached Final status in May 2026, which means the interface is frozen: implementers can build against it without expecting the signatures to change.
The interesting design decision is what the standard refuses to do. It addresses those four areas without binding implementers to a specific identity provider or jurisdictional framework — so it specifies that a compliant token must be able to say whether a transfer is permitted, and says nothing whatsoever about how it should reach that conclusion. That restraint is what makes a single interface viable across instruments governed by incompatible legal regimes.
The specification provides “flexible compliance” through view functions “without dictating how those checks are implemented internally.”
— ERC-7943: uRWA — Universal Real World Asset Interface, rationale section
Previous attempts at RWA standards often bundled an opinion about identity or jurisdiction into the specification, which made them excellent for the market they were designed around and unusable elsewhere. An interface that declines to have that opinion can be adopted by a US Reg D offering, an EU UCITS share class and a Singapore CIS unit without any of them adopting each other's compliance model.
The Four Primitives
The standard defines three interfaces — fungible, non-fungible and multi-token, each implementing IERC165 — carrying the same conceptual functions with type-appropriate parameters. Four of them do the compliance work, and each has behavioural requirements the specification states as MUST.
| Function | Question it answers | Required behaviour |
|---|---|---|
| canSend(account) | May this account part with the asset? | Must not revert; must not change storage |
| canReceive(account) | May this account acquire the asset? | Must not revert; must not change storage |
| canTransfer(from, to, amount) | Is this specific transfer permitted? | Must check the amount against the unfrozen balance, and must call canSend on the sender and canReceive on the recipient |
| forcedTransfer(from, to, amount) | Enforcement — move the asset regardless | Must manipulate balances directly; must be access-restricted; must emit ForcedTransfer |
| setFrozenTokens(account, amount) | Immobilise a quantity | Must allow freezing more than is held; must emit Frozen; restricted to authorised actors |
| getFrozenTokens(account) | How much is immobilised? | Returns an absolute amount, which may exceed the current balance |
Key Insight
The rule that freezing may exceed the balance held looks like a specification error and is the opposite. Consider a court order to freeze 1,000 units against an account holding 400: if freezing were capped at the balance, the holder could receive 600 more and move them before anyone re-applied the order. Allowing an absolute frozen quantity above the balance means the obligation attaches to the account rather than to the current position, and incoming units land already immobilised. That is how a freeze works in conventional finance, and reproducing it required an explicit rule most token designs get wrong.
Why Send and Receive Are Separate Questions
The specification mandates a separation of concerns between account eligibility, expressed by canSend and canReceive, and transfer-level authorisation, expressed by canTransfer. The stated rationale is that this enables one-way restrictions where an account may be blocked from receiving but still allowed to send.
That asymmetry is not an edge case in regulated markets — it is the normal state of a holder who loses eligibility after acquiring a position. An investor whose accreditation lapses, a holder who moves to a restricted jurisdiction, a party subject to a new sanctions designation: in each case the correct outcome is that they acquire no more and can still exit. A design with a single boolean per account cannot express that, and forces a choice between trapping the holder and letting the position grow.
Can send, can receive
The ordinary eligible holder. Transfers proceed subject to the amount check against unfrozen balance.
Can send, cannot receive
Eligibility lost after acquisition. The holder must be able to exit the position but must not accumulate more — the case the separation exists to express.
Cannot send, can receive
A lock-up, a pledge, or a holding-period restriction. The position can grow but cannot be moved out.
Neither
A fully restricted account. Movement requires the enforcement path — forcedTransfer by an authorised actor — rather than an ordinary transfer.
The fourth state is why forcedTransfer exists. A token representing a regulated security has to be movable by an authorised party in circumstances the holder does not consent to — a court order, a corporate action, a correction of an erroneous transfer, a recovery from a compromised wallet. The standard requires that this power be access-restricted and that its use emit a ForcedTransfer event, which is the minimum needed for it to be auditable rather than invisible.
What Conformance Does Not Give You
A token conforming to ERC-7943 is not thereby compliant with anything. The standard defines only essential functions without mandating specific implementation approaches, so a conforming token whose canTransfer returns true unconditionally satisfies the interface completely while enforcing nothing at all.
This needs saying because interface conformance is easy to present as a compliance credential. The useful reading is narrower and still valuable: conformance tells an integrator how to ask the question, not that the answer is correct. Diligence on a conforming token still has to establish who controls the eligibility logic, what it actually checks, who holds the forcedTransfer permission, and under what governance that permission is exercised.
| The standard fixes | The issuer still owns |
|---|---|
| That a token can be asked whether a transfer is permitted | What the eligibility rules are, and whether they match the offering terms |
| That enforcement transfers emit an auditable event | Who may invoke enforcement, and under what governance |
| That frozen amounts are readable and may exceed balance | Who may freeze, on what legal basis, and how it is unwound |
| That eligibility and authorisation are distinct checks | Which identity source feeds them and how current it is |
| A common integration surface across instruments | The legal classification of the instrument and everything that follows |
The right-hand column is the substance of a compliant program, and none of it is a standards problem. Classification in particular sits entirely outside the interface — a conforming token can be a security, and the obligations that creates are examined in who is the transfer agent for a tokenized security.
What Standardisation Actually Changes
The benefit accrues to integrators rather than issuers. A custodian, exchange or lending protocol that implements the uRWA interface once can then evaluate any conforming token — call canTransfer before attempting a move, read getFrozenTokens to understand encumbrance, and watch ForcedTransfer and Frozen events to keep records aligned.
That matters because integration cost has been a real constraint on regulated instruments reaching institutional platforms. A custodian asked to support a bespoke compliant token has to review unfamiliar contract logic, work out which functions can move a holder's position, and decide whether it can operate the asset safely — a per-issuer diligence exercise that does not amortise. A common interface converts that into a one-time integration plus per-instrument checks on what the logic decides.
Adoption has breadth behind it. The coalition supporting the standard has grown since its September 2025 announcement to span the full RWA stack — issuance platforms, infrastructure providers, exchanges, marketplaces, identity vendors and audit firms — with contributors including Bit2me, Brickken, Casper Network, CMTA, Compellio, Dekalabs, DigiShares, Forte Protocol, FullyTokenized, Propchain, RealEstate.Exchange, Stobox and Zoth. Breadth across the stack matters more than any single name, because an interface only pays off when both sides of an integration implement it.
The relationship to existing standards is complementary rather than competitive. ERC-7943 maintains compatibility with ERC-20, ERC-721, ERC-1155 and ERC-6909 as an interface layer, so a token can present the uRWA interface while implementing its compliance through richer machinery underneath — the standards landscape is set out in the RWA token standards guide.
Who Should Adopt It, and Where It Falls Short
Issuers wanting their instrument to be integrable by custodians and venues without bespoke work should conform. Integrators building once against many instruments should implement the interface. Neither should treat conformance as evidence about the quality of the compliance logic behind it.
Good fit
- Instruments needing broad custodial support
- Programs spanning multiple jurisdictions
- Venues integrating many issuers
- Anything requiring enforcement and freeze primitives
Still to verify
- What the eligibility logic actually checks
- Who holds forcedTransfer permission
- Whether the identity source is current
- How a freeze is authorised and unwound
Outside its scope
- Legal classification of the instrument
- Identity verification and its standards
- Off-chain register reconciliation
- Settlement finality and its legal dimension
The last item is the boundary worth naming. A canTransfer that returns true tells an integrator the token will move; it says nothing about when the recipient holds an enforceable right, which is a question about the authoritative record rather than the contract — set out in when a tokenized transfer is actually final. A standard that governs the token cannot resolve a question about the register.
How Blockmaze Relates to the Interface
ERC-7943 specifies where the compliance questions are asked. What decides them is a separate layer, and the standard's neutrality on that point is precisely what makes a protocol-level compliance engine composable with it rather than redundant to it.
Eligibility Behind the Interface
canSend, canReceive and canTransfer resolve against protocol-level identity and jurisdiction rules, so the interface a venue integrates against is backed by enforcement rather than a permissive stub.
Enforcement Authority Declared
Who may invoke forcedTransfer or freeze a position is an explicit, auditable governance fact rather than an admin key discovered during diligence.
Freeze State Reconciled
Frozen quantities recorded on-chain correspond to the off-chain basis for the freeze, so getFrozenTokens reports an encumbrance a counterparty can rely on.
Rules Versioned per Jurisdiction
Because the standard is jurisdiction-neutral, the rules behind it are held per jurisdiction and versioned by effective date rather than compiled into the token.
The division of labour is clean and worth preserving. A frozen interface should stay frozen — that is what makes it integrable — while the rules behind it change as often as regulation does. Building those rules into the token would have made the standard obsolete on its first regulatory change, which is exactly the failure mode its neutrality avoids.
Implementing a Compliant Token Interface?
Blockmaze provides the compliance layer behind the interface — eligibility resolved against protocol-level rules, declared enforcement authority, reconciled freeze state, and rules versioned per jurisdiction.
Frequently Asked Questions
What is ERC-7943?
ERC-7943, the Universal Real World Asset (uRWA) interface, is an Ethereum standard defining a minimal, vendor-neutral interface for the compliant tokenization of real-world assets. It reached Final status in Ethereum's formal standards process in May 2026, meaning its interface, error definitions, event signatures and behavioural requirements are frozen and available for production adoption across Ethereum and EVM-compatible networks. It addresses transfer validation, asset freezing, forced transfers and enforcement actions without binding implementers to a specific identity provider or jurisdictional framework.
What functions does the standard actually define?
Four compliance primitives plus accessors, across three interfaces for fungible, non-fungible and multi-token assets. canSend(address) and canReceive(address) are account-level eligibility checks. canTransfer(from, to, amount) is a transfer-level authorisation that must validate the amount against the unfrozen balance and must itself perform canSend on the sender and canReceive on the recipient. forcedTransfer(from, to, amount) directly manipulates balances for enforcement and must be access-restricted. setFrozenTokens and getFrozenTokens manage and report frozen amounts, which may exceed an account's current balance.
Why separate canSend and canReceive from canTransfer?
Because account eligibility and transfer authorisation are different questions, and collapsing them loses cases that matter in regulated markets. The specification mandates the separation explicitly, and the rationale gives the reason: it enables one-way restrictions where an account may be blocked from receiving but still allowed to send. That is exactly the state a holder occupies when they lose eligibility — a sanctioned party, an investor whose accreditation lapsed, a jurisdiction that becomes restricted. They should not accumulate more of the asset, and they must still be able to exit.
What does the standard deliberately not specify?
How any of the checks decide. The standard provides flexible compliance through view functions without dictating how those checks are implemented internally, and does not bind implementers to a specific identity provider or jurisdictional framework. That is the deliberate boundary: ERC-7943 standardises the questions a compliant token must be able to answer, not the answers. Two conforming tokens can implement radically different eligibility logic, source identity from different providers, and enforce different jurisdictional rules, while presenting an identical interface to any integrator.
Does ERC-7943 replace ERC-3643?
No — it operates at a different level. ERC-7943 is an interface layer maintaining compatibility with existing standards including ERC-20, ERC-721, ERC-1155 and ERC-6909, and defines only essential functions without mandating implementation approaches. ERC-3643 (T-REX) is a fuller framework that specifies an identity registry and compliance module architecture. A token can present the uRWA interface while implementing its compliance through T-REX machinery underneath. The relationship is one of interface to implementation rather than competing alternatives.
What does adopting it actually buy an issuer?
Integration surface rather than compliance. A custodian, exchange or lending protocol that has integrated the uRWA interface once can evaluate any conforming token without bespoke work — call canTransfer before attempting a move, read getFrozenTokens to understand encumbrance, listen for the ForcedTransfer and Frozen events. That reduces the integration cost that has kept regulated instruments off institutional platforms. It does not make an issuer compliant, because the standard is silent on what the checks should decide, which remains the issuer's legal problem.
Related Articles
RWA Token Standards Guide
The wider standards landscape and what each enforces at the token level.
Evolving RWA Token Standards and Compliance
How the standards have developed and what drives the changes.
On-Chain Proof Enforcement for RWA Compliance
Why eligibility enforced before settlement is different from eligibility checked after it.
Who Is the Transfer Agent for a Tokenized Security?
The register obligations that the forced transfer and freeze primitives exist to serve.