Token standards
ERC-7943 gives a tokenized security the vocabulary an ordinary ERC-20 lacks: a forced transfer for seizure and recovery, an absolute frozen amount, and checks the token answers itself about who may send and who may receive. Tokenistry Core implements it on an ERC-20 that runs in production, in your own environment.
A regulated instrument needs operations a payment token never has to think about. Units have to be frozen without being taken. A court order has to be executable. A lost key has to be recoverable. A transfer to an ineligible wallet has to fail, and fail for a reason a counterparty can read.
Before ERC-7943 every issuer invented these separately, which produced tokens only their
authors understood and integrations that had to be written once per issuer. The uRWA
interface, reproduced from the standard as
IERC7943Fungible in our contracts, fixes the shape of those operations so
custodians, auditors and counterparties can rely on them.
The uRWA token standard is six functions, two events and four errors. That is the whole surface, which is why it is implementable over an existing ERC-20 rather than a migration.
| Member | Kind | What it does |
|---|---|---|
canSend(address) |
view | Whether an account is permitted to send under the token's own rules. |
canReceive(address) |
view | Whether an account is permitted to receive. Separate from sending, because a lock-up and a sanction are different situations. |
canTransfer(from, to, amount) |
view | Whether one specific transfer would succeed right now, frozen balance included. This is the call an integrator makes before signing anything. |
getFrozenTokens(address) |
view | The absolute frozen amount for an account. It may exceed the balance, which is deliberate. |
setFrozenTokens(address, amount) |
state | Overwrites the frozen amount rather than adding to it, the same way approve works. Two callers cannot race into a larger freeze than either intended. |
forcedTransfer(from, to, amount) |
state | Moves units without the holder's signature. Seizure, recovery, court order. |
ForcedTransfer(from, to, amount) |
event | Every forced move leaves a record an auditor can reconstruct from chain data alone. |
Frozen(account, amount) |
event | Emitted with the resulting amount, not the delta, so the event carries the state. |
ERC7943CannotSend(account) |
error | The sender is not permitted. |
ERC7943CannotReceive(account) |
error | The recipient is not permitted. |
ERC7943CannotTransfer(from, to, amount) |
error | Both parties are permitted but this transfer is not. |
ERC7943InsufficientUnfrozenBalance(account, amount, unfrozen) |
error | The holder has the balance but not enough of it unfrozen, and the error says how much is actually available. |
Four distinct errors rather than one generic revert is the detail that matters in operations. When a transfer fails at three in the morning, the difference between "recipient is not whitelisted" and "holder has 400 units frozen, 100 available" is the difference between a support ticket and an incident.
ERC-7943 is discoverable through ERC-165. The ERC-20 flavour has interface ID
0x3edbb4c4, so a custodian integrating your instrument can call
supportsInterface and get a definitive answer from the contract itself.
That check is asserted in our test suite rather than assumed, and it is the reason a counterparty can onboard your token without a bilateral conversation about what it supports.
transfer.check
The question is not which standard is better. It is how much of your architecture you want the standard to decide.
| ERC-3643 (T-REX) | ERC-7943 (uRWA) | |
|---|---|---|
| Scope | A system. Identity registry, verified claims, modular compliance contracts. | An interface. The operations and checks a regulated token exposes. |
| Identity model | Prescribed. Investors carry an on-chain identity that claims are issued against. | Not prescribed. The token answers whether a wallet may act; what stands behind that answer is yours. |
| Token types | ERC-20. | Written per token type, so the same operations carry across fungible and non-fungible instruments. |
| Fits when | You want an identity and claims framework supplied with the standard and are content to adopt it. | Your KYC, AML and eligibility decisions already live in systems you own, and you want them enforced on chain without a second identity model beside them. |
ERC-3643 is the older and more widely deployed of the two, and if an identity registry is something you want rather than something you tolerate, it is a reasonable choice. We build on ERC-7943 because the institutions we work with have already spent years and money deciding who is eligible to hold what. Those decisions live in their onboarding systems, under their auditors. Asking them to restate the same facts as on-chain claims adds a second source of truth to keep in step with the first.
What ERC-7943 leaves open, a production system still has to close. That is the difference between an interface and a product, and it is the next section.
The standard says what a token exposes. It does not say where permission comes from, how the code is upgraded, or who is allowed to seize units.
| Contract | What it closes |
|---|---|
RWAToken |
The instrument. An ERC-20 implementing ERC-7943, with ERC-2771 so an investor can transfer without holding native currency, and a role for each privileged operation rather than one administrator who can do everything. |
ComplianceRegistry |
Where canSend and canReceive get their answers. Permission lists of wallets with separate send and receive flags, attachable to several tokens at once. A token with no list attached cannot be minted or moved, so the untouched state is inert rather than open. |
RWATokenFactory |
Deploys each token as a beacon proxy using CREATE2, so the address is known before the transaction is mined and can appear in documents drafted in advance. |
RWATokenBeacon |
Where every token reads its logic from. One upgrade migrates an issuer's whole book, upgrade authority lives here alone, and no token role can reach it. |
Deploying a token grants administration and nothing else. Minting, burning, freezing and forced transfer are separate grants, which is inconvenient exactly once and the reason a compromised service cannot quietly do all four. Both the administrative and the upgrade authorities are held by you, not by Tokenistry.
There is no pause function. The equivalent, and a stronger one because it stops minting too, is detaching every compliance list, which makes the token's own checks fail closed. The meta-transaction forwarder cannot reach the beacon, so the path that lets an investor transfer without gas is not a path to the code behind their token.
The quickstart brings up the whole stack against a public
testnet in one command. Mint, freeze an amount, attempt a blocked transfer, and watch
it revert with ERC7943InsufficientUnfrozenBalance naming the amount
actually available.
Contracts are developed and tested with Foundry across unit, fuzz, invariant and mainnet-fork suites, the uRWA interface ID assertion included. Source can be published and verified on chain, so the bytecode running your book is the code you reviewed.
ERC-7943 is the uRWA interface, a standard set of administrative operations a tokenized real-world asset needs: a forced transfer for seizure and recovery, an absolute frozen amount per account, and view functions that answer whether a given account may send, may receive, or whether a specific transfer would succeed. It is an interface rather than a full system, so it says what a compliant token must expose without dictating how eligibility is decided.
For the ERC-20 flavour the interface ID is 0x3edbb4c4. Because the token also implements ERC-165, a counterparty can call supportsInterface(0x3edbb4c4) and get a definitive answer from the contract instead of relying on documentation.
ERC-3643 specifies a system: an on-chain identity registry, verified claims about investors and modular compliance contracts. ERC-7943 specifies an interface: the operations and checks a regulated token exposes, with the mechanism behind them left open. ERC-3643 decides more of your architecture for you. ERC-7943 fits a firm that already owns its eligibility decisions and wants those enforced on chain without adopting an identity model alongside them.
Yes. ERC-7943 is additive. The token is an ERC-20 first, so custody platforms, wallets, accounting systems and analytics already understand its balances and transfers. The uRWA functions sit on top for the operations a security needs and an ordinary ERC-20 has no vocabulary for.
No. The standard defines canSend, canReceive and canTransfer as questions the token answers. What stands behind those answers is the implementer's choice. In Tokenistry Core it is an on-chain compliance registry holding per-wallet send and receive flags, populated from eligibility decisions your own KYC and AML systems make.
No. forcedTransfer is the operation a court order or a lost-key recovery needs, so it is gated behind its own role rather than granted with general administration. Deploying a token grants administration and nothing else; minting, burning, freezing and enforcement are each granted explicitly, and every forced transfer emits a ForcedTransfer event that an auditor can reconstruct from chain data alone.
Yes. The quickstart brings up the whole stack against a public testnet, including the token, the compliance registry and the operator console, so you can mint, freeze an amount, attempt a blocked transfer and watch it revert with the standard error.
We can walk through what ERC-7943 leaves open and how your eligibility decisions would reach the chain.
Discuss your architecture