RWA Token Standards

AI-assisted manuscript. Code interfaces are educational; no contract is deployed or certified.

Learning objectives

• Distinguish a token interface from financial rights and policy.
• Compare ERC-20 and ERC-3643 at their stated boundaries.
• Translate a business requirement into an enforceable check and an explicit unknown.

Interfaces help systems communicate

A token standard specifies expected operations and behavior so applications can interact consistently. ERC-20 defines operations including balances, transfers, approvals and allowances. Its metadata methods such as name, symbol and decimals are optional, and callers must handle a false result from relevant calls. It does not define ownership of an external asset, a redemption promise or investor eligibility. ERC-20

ERC-3643 describes a permissioned token architecture using identity registries, claims and compliance components. Its identity registry associates a wallet with an identity and country information, while verification and compliance checks participate in deciding permitted transfers. This is a technical design for specified controls, not a worldwide legal-compliance certificate. ERC-3643

Neither standard removes the need for instrument documents, current evidence and authorized policy decisions. A standard can make a rule available to enforce; the rule still needs to be correct for the particular arrangement.

Worked example: transferable balance, expired permission

Imagine a fictional fund token with 1,000 units held by Alice. Alice requests to transfer 100 to Ben. A balance-only teaching implementation checks that Alice has at least 100 and updates balances. A permissioned teaching implementation also checks that Ben's product permission is current and that the transaction meets the specified concentration rule.

Suppose Ben's permission expired yesterday. The desired result under these assumed rules is no transfer, with balances remaining Alice 1,000 and Ben unchanged. A function existing in a standard is not evidence that the application actually invokes the relevant policy. The implementation must trace the transfer path through the enforcement owner and test the forbidden case.

Now suppose Alice approves another contract to spend 100. An allowance is not itself evidence that Ben is eligible or that the external asset transfer is legally recognized. Delegated spending and recipient permission answer different questions.

Business requirement: only currently eligible recipients
        ↓
Policy definition + evidence + expiry rule
        ↓
Registry / verification / transaction compliance
        ↓
Every relevant transfer path, including delegated operations
        ↓
Success or rejection with invariant balances and audit evidence

The example's concentration and expiry rules are invented. Do not mistake them for requirements imposed by either standard in every deployment.

Evaluate an implementation, not a standard name

Record the exact specification version, contract version, deployed addresses if relevant, privileged roles, upgrade mechanism and test evidence. Check minting, burning, transfers, delegated transfers, recovery and exceptional actions separately. A restriction implemented for the main button may be absent from another writer.

Ask what is external: who verifies identity, how claims expire, how an oracle supplies facts and how the recognized asset register is reconciled. The token interface cannot independently inspect a building or resolve a legal dispute. Also consider compatibility: a protocol expecting unrestricted transfers may reject or mishandle a restricted token. Integration testing needs allowed and forbidden paths, not only a compilation result.

Common misconceptions

“ERC-20 means suitable for every financial instrument.” A generic interface does not include every required permission or servicing rule.

“ERC-3643 means legally approved everywhere.” Technical policy architecture and legal authorization are different evidence.

“Metadata establishes the represented right.” A symbol or decimals value describes an interface field, not asset title.

Risks and limits

Standards and libraries can change. The source versions directly read on 2026-10-18 ground this lesson; actual deployment requires current version and implementation review. This chapter does not audit a contract, recommend deployment or determine securities compliance. Its diagrams describe a teaching boundary only.

Exercise and answer

Exercise: Ben has an expired permission but an address that can receive ordinary ERC-20 transfers. Under the stated permissioned model, should a delegated transfer bypass eligibility?

Answer: No. Delegation changes who submits the spending instruction; it does not remove the assumed recipient rule. Test all relevant transfer writers and preserve balances on rejection.

Related learning

Continue in engineering with identity registries, access control and reconciliation. Use Build only within its stated educational scope.

Source map

erc20 and erc3643 are technical specifications from Ethereum Improvement Proposals, directly read by the source-analysis role on 2026-10-18. Their scope is software behavior, not jurisdictional approval. People, balances and policy rules are original examples; no deployed contract was tested.