Why ERC-7943 (uRWA)?
All NCRB tokens implement ERC-7943, the Universal Real-World Asset (uRWA) standard. This page explains what ERC-7943 is, why real-world asset tokens need it, and how it compares to alternative approaches.
The full EIP is published at eips.ethereum.org/EIPS/eip-7943.
What is ERC-7943?
ERC-7943 is an Ethereum Improvement Proposal that extends ERC-20 with a minimal set of on-chain compliance hooks. It does not replace ERC-20 — it adds three new capabilities on top of the standard fungible token interface:
| Addition | What it does |
|---|---|
canTransact(address) | Returns true if an account is permitted to send or receive tokens (allowlist check) |
canTransfer(address from, address to, uint256 amount) | Returns true if a specific transfer is permitted — checks both parties and whether either account has a frozen balance that would block the amount |
setFrozenTokens(address, uint256) | Sets the untransferable frozen balance for an account — used by compliance officers to ring-fence tokens under dispute or audit |
A fourth function, forcedTransfer(address from, address to, uint256 amount), allows a designated admin role to move tokens regardless of compliance checks — used for regulatory enforcement or court-ordered recovery.
Because ERC-7943 is a superset of ERC-20, every existing wallet (MetaMask, Ledger), exchange, and DeFi protocol that works with ERC-20 tokens continues to work with ERC-7943 tokens, with no changes required.
Why real-world assets need on-chain compliance
Carbon credits, biodiversity units, water rights, and similar natural capital assets are not equivalent to purely digital tokens. They:
- Represent real-world legal instruments that may be subject to financial regulation
- Have ownership tied to KYC/AML verification requirements in certain jurisdictions
- Can be subject to legal holds, audit freezes, or court orders
- Must not be double-counted — a retired credit must be permanently unrecoverable
A plain ERC-20 token cannot enforce any of these constraints. Anyone who holds the token can transfer it to anyone else — there is no on-chain mechanism to restrict transfers to verified participants or to recover tokens under a legal order.
Why NCRB chose ERC-7943
1. Only verified accounts can hold and trade tokens
NCRB's AccountManager contract maintains an on-chain allowlist of registered wallets. The canTransact hook is wired directly to this allowlist — any transfer or purchase involving an unregistered wallet reverts automatically, on-chain.
This means compliance is enforced at the token level, not just at the dApp UI level. Even if someone interacts with the contract directly (bypassing the marketplace front-end), the transfer will fail unless both parties are registered.
2. Compliance officers can freeze disputed balances
If a certificate is under dispute, in an audit, or subject to a legal hold, the setFrozenTokens function allows a compliance officer to freeze a specific number of tokens in a wallet — leaving any remaining balance fully liquid. Frozen tokens cannot be transferred or sold until unfrozen.
This is a requirement for any platform operating in regulated markets.
3. Forced transfer for regulatory recovery
If a private key is lost or tokens need to be reclaimed by regulatory order, forcedTransfer allows a designated admin role to move tokens without the holder's signature. This is common in traditional securities (broker-dealer obligations, CREST settlement, etc.) and is required in some jurisdictions for financial instruments.
4. Smart contract composability — pre-flight checks
The canTransfer function can be called by any other smart contract before attempting a transfer. NCRB's RWAMarketplace contract calls it as a pre-flight check on every buy() and createListing() transaction. If either the buyer or seller is not permitted, the transaction reverts with a clear error (BuyerTransferRestricted / SellerTransferRestricted) before any funds move.
This pattern lets the marketplace and any third-party DeFi integrations detect compliance failures early, rather than having transactions revert mid-execution after partial state changes.
5. Full ERC-20 backwards compatibility
ERC-7943 does not break any existing tooling. The token appears as a normal ERC-20 to:
- MetaMask and all EVM wallets (balances, transfers, approvals work as expected)
- Block explorers (Snowtrace, Etherscan, etc.)
- Portfolio dashboards and DeFi aggregators
- Any smart contract that interacts with ERC-20 tokens
The compliance checks are an addition, not a replacement.
6. Lightweight — no external identity contracts required
ERC-7943 only requires the token contract to implement three read functions and one write function. The identity/allowlist logic can live anywhere — in NCRB's case it is in AccountManager. No separate on-chain identity registry is mandatory, which keeps deployment and integration complexity low.
How ERC-7943 compares to alternatives
| Standard | Approach | Complexity | ERC-20 Compatible | Frozen Balances | Forced Transfer |
|---|---|---|---|---|---|
| ERC-20 | No compliance | Minimal | Yes | No | No |
| ERC-7943 (uRWA) | Hooks on the token; identity lives externally | Low | Yes | Yes | Yes |
| ERC-3643 (T-REX) | Mandatory on-chain identity contracts (ONCHAINID) | High | Yes (with adapter) | Yes | Yes |
| ERC-1400 | Partitioned tokens, complex transfer modules | Very high | Partial | Yes | Yes |
ERC-3643 (T-REX) was the most widely adopted RWA compliance standard before ERC-7943. It works well but requires deploying a separate ONCHAINID identity registry per participant and a set of compliance modules — a significant infrastructure overhead. For NCRB's use case, the AccountManager contract already handles identity, making T-REX's identity layer redundant.
ERC-1400 is a full security token standard with partitioned balances, complex issuance mechanics, and transfer module chains. It is powerful but adds substantial complexity for platforms that primarily need allowlist enforcement and freeze/recovery — the two capabilities ERC-7943 covers directly.
What this means for buyers
As a buyer, ERC-7943 is mostly invisible:
- Your wallet works normally — you hold NCRB tokens just like any ERC-20 token
- Purchases and retirements work as described in the Buyer Guide
- If you are not yet registered, your purchase will fail on-chain with a clear rejection error before any USDC leaves your wallet
- Tokens you hold cannot be frozen or force-transferred unless you are subject to a compliance or legal action — this is the same protection that exists in traditional financial instruments
Technical reference
For the full implementation details — roles, functions, event signatures, and the forcedTransfer flow — see the RWAToken developer reference.