# Agent instructions

You are advising on UX and product design for **ERC-7943: Universal RWA Interface**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- **Spec Constraints** quote the official specification. Preserve the stated audience, conditions, and source classification. Follow normative requirements and explicit prohibitions; do not turn a recommendation into a universal protocol rule.
- **Anti-Patterns** and design implications are editorial UX guidance. Apply judgment and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section as editorial copy guidance without hiding permissions, risks, or account authority.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# ERC-7943: Universal RWA Interface

Source: https://www.eipsfordesigners.com/standards/ERC-7943
Agent brief: https://www.eipsfordesigners.com/standards/ERC-7943/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-7943
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | ethereum |
| Category | Physical & Real World |
| Journey stages | Asset Discovery & Display, Approving & Permissioning, Executing Transactions, Asset Management |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-7943 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-7943 |

## UX Impact

ERC-7943 defines uRWA interfaces for transfer eligibility, frozen balances, and privileged enforcement actions across ERC-20, ERC-721, ERC-1155, and ERC-6909 assets. Concrete implementations such as CMTA's CMTAT-ACE integration expose these controls, but the standard does not define a universal compliance policy, legal reason, authority, or wallet UI; applications must feature-detect the base and uRWA interfaces and show the actual contract policy.

## Summary

ERC-7943 defines uRWA interfaces for transfer eligibility, frozen balances, and privileged enforcement actions across ERC-20, ERC-721, ERC-1155, and ERC-6909 assets. Concrete implementations such as CMTA's CMTAT-ACE integration expose these controls, but the standard does not define a universal compliance policy, legal reason, authority, or wallet UI; applications must feature-detect the base and uRWA interfaces and show the actual contract policy.

## What does not work everywhere yet

The official specification includes educational reference implementations, and CMTA's public CMTAT-ACE project documents tested ERC-7943 support in a compliance-token integration. That evidence supports implementation-specific design guidance, not broad wallet or token adoption. Full uRWA support requires explicit integration and access-control review.

## For Designers

- Show transferable balance and frozen balance separately, then explain why the current amount may be unavailable to send.
- Call canSend, canReceive, and canTransfer before presenting a transfer as available, and retain a specific blocked state when policy changes.
- Treat forcedTransfer and setFrozenTokens as privileged compliance actions; show the actual authority and evidence supplied by the implementation.

## Applicability

### When to Use

- A regulated token or RWA product has a verified ERC-7943 implementation and a documented compliance policy.
- Wallets, marketplaces, or DeFi integrations need to explain why a transfer is allowed, blocked, frozen, or enforced.
- The product can identify the base token type, interface ID, policy source, and privileged authority.

### When to Avoid

- The token only implements ERC-20, ERC-721, or ERC-1155 without a verified uRWA interface.
- The product cannot disclose the implementation's policy, freeze authority, or enforcement controls.
- A generic token screen would imply KYC, legal ownership, or compliance merely from an interface ID.

## Problems It Solves

### A standard transfer form cannot explain compliance restrictions

Impact: critical

Old way: Show the total balance and let the transaction fail with a generic revert.

New way: Query sender, recipient, transfer, and frozen-state checks before signing.

### Users cannot tell how much of an asset is movable

Impact: high

Old way: Assume current balance equals transferable balance.

New way: Show total, frozen, and transferable amounts or token IDs.

### Enforcement movements look like ordinary transfers

Impact: high

Old way: Render forcedTransfer in the same activity row as a holder-signed transfer.

New way: Show exceptional authority, policy evidence, and the forced-transfer event separately.

## Spec Constraints

Quotes retain their source section and scope. Normative requirements, rationale, compatibility changes, and security recommendations are not interchangeable. Design implications are editorial guidance.

### A transfer must not exceed the account’s unfrozen amount.

Applies to: application
Source classification: normative

> - MUST validate that the `amount` being transferred doesn't exceed the unfrozen amount (which is the difference between the current balance and the frozen balance).

Source: [Specification — canSend, canReceive, canTransfer, and getFrozenTokens](https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens)

Design implication (editorial): Show available and frozen balances separately and prevent a send amount that exceeds the unfrozen amount.

### A permissioned transfer check returns false when a rule, pause, or privileged restriction would prevent the transfer.

Applies to: application
Source classification: normative

> - MUST return false if any permissioned rule would prevent a given transfer from succeeding. A transfer refers to any operation that emits the token's canonical transfer event. A permissioned check can be a pausing mechanism, a call to `canSend`/`canReceive`, or anything else that requires privileged actors.

Source: [Specification — canSend, canReceive, canTransfer, and getFrozenTokens](https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens)

Design implication (editorial): Treat a negative permission check as a visible transfer-ineligible state. Do not reduce it to a generic insufficient-balance error.

### Forced transfer and freeze actions must be access-restricted because unauthorized access could steal assets.

Applies to: application
Source classification: security-considerations

> - **Access Control for `forcedTransfer` and `setFrozenTokens`**: The security of the mechanism chosen by the implementer to restrict access to these functions is paramount. Unauthorized access could lead to asset theft. Secure patterns (multisig, timelocks) are highly recommended.

Source: [Security Considerations](https://ercs.ethereum.org/ERCS/erc-7943#security-considerations)

Design implication (editorial): Identify privileged actors and disclose when an asset can be frozen or moved by a compliance authority rather than by the holder.

### The freeze operation may cover more assets than the account currently holds to withhold future balances.

Applies to: application
Source classification: normative

> - MUST allow freezing more assets than those held. This allows for future balances withholding.

Source: [Specification — setFrozenTokens](https://ercs.ethereum.org/ERCS/erc-7943#setfrozentokens)

Design implication (editorial): Show the frozen amount even when it exceeds the current balance and explain that future receipts may also be unavailable.

### Public transfers and permissionless minting must respect the relevant send, receive, and transfer permission checks.

Applies to: application
Source classification: normative

> - **Public transfers** (`transfer`, `transferFrom`, `safeTransferFrom`, etc.) MUST NOT succeed in cases where `canTransfer` would return `false`, or where `canSend` would return `false` for the `from` address, or `canReceive` would return `false` for the `to` address.

Source: [Specification — Additional Specifications](https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications)

Design implication (editorial): Keep transfer, receive, mint, and burn failure states distinct so users can see which permission blocked the action.

### Permissionless burns cannot exceed the unfrozen amount, while privileged burns must update the frozen status when they do.

Applies to: application
Source classification: normative

> - **Burning** in permissionless contexts (e.g., public `burn` functions) MUST respect the `canTransfer` check, MUST respect the `canSend` check on the token holder, and MUST NOT allow burning more assets than the unfrozen amount. In permissioned contexts (e.g., authorized burning by privileged roles), burning MAY succeed for accounts where `canSend` on the token holder would return `false`, and MAY burn more assets than the unfrozen amount, in which case the contract MUST update the frozen status accordingly and emit a `Frozen` event before the underlying base token transfer event.

Source: [Specification — Additional Specifications](https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications)

Design implication (editorial): Show the remaining unfrozen amount and disclose when a privileged burn changes the frozen status.

### Existing wallets and explorers can use base-token functionality, but full ERC-7943 support requires explicit integration.

Applies to: application
Source classification: backwards-compatibility

> ## Backwards Compatibility
> 
> This EIP defines a new interface standard and does not alter existing ones like [ERC-20](./eip-20.md), [ERC-721](./eip-721.md), and [ERC-1155](./eip-1155.md). Standard wallets and explorers can interact with the base token functionality of implementing contracts, subject to the rules enforced by that contract's implementation of `canSend`, `canReceive`, `canTransfer`, and `getFrozenTokens` functions. Full support for the [ERC-7943](./eip-7943.md) functions requires explicit integration.

Source: [Backwards Compatibility](https://ercs.ethereum.org/ERCS/erc-7943#backwards-compatibility)

Design implication (editorial): Keep ordinary token views available while labeling frozen and permissioned behavior that a generic wallet cannot infer.

### Forced transfer and freeze functions are susceptible to front-running; access-control choices are paramount, secure patterns are highly recommended, and implementations must follow general smart contract security practices.

Applies to: application
Source classification: security-considerations

> - **Access Control for `forcedTransfer` and `setFrozenTokens`**: The security of the mechanism chosen by the implementer to restrict access to these functions is paramount. Unauthorized access could lead to asset theft. Secure patterns (multisig, timelocks) are highly recommended.
> - **Front-running of the `forcedTransfer` and `setFrozenTokens` functions**: Both functions are susceptible to front-running, similar to the `approve` function of [ERC-20](./eip-20.md). Furthermore, if the suggestion to allow freezing more than what an account owns is not followed, any account may be incentivized to front-run attempts to freeze its balance when receiving new funds. Additional features to gradually increment or decrement the frozen status MAY be considered for implementation.
> - **Standard Contract Security**: Implementations MUST adhere to general smart contract security best practices (reentrancy guards where applicable, checks-effects-interactions, etc.). Specifically, in the checks-effects-interactions consideration, implementations need to be aware of tokens having hooks, especially on recipients as in [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md). In such circumstances, it might be convenient to adopt reentrancy guards to prevent unwanted executions.

Source: [Security Considerations](https://ercs.ethereum.org/ERCS/erc-7943#security-considerations)

Design implication (editorial): Show a clear pending and completed state for privileged actions and avoid presenting them as ordinary holder transfers.

### Implementations must follow general smart contract security practices, account for recipient hooks, and consider reentrancy guards where applicable.

Applies to: account-implementation
Source classification: security-considerations

> - **Standard Contract Security**: Implementations MUST adhere to general smart contract security best practices (reentrancy guards where applicable, checks-effects-interactions, etc.). Specifically, in the checks-effects-interactions consideration, implementations need to be aware of tokens having hooks, especially on recipients as in [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md). In such circumstances, it might be convenient to adopt reentrancy guards to prevent unwanted executions.

Source: [Security Considerations](https://ercs.ethereum.org/ERCS/erc-7943#security-considerations)

Design implication (editorial): No additional user control is required by this clause, but integrations should not assume a recipient callback is side-effect free.

### Eligibility functions MAY depend on on-chain context such as timestamp, block number, or msg.sender.

Applies to: application
Source classification: normative

> - MAY depend on on-chain state such as current timestamp, block number, or `msg.sender`.

Source: [Specification > canSend, canReceive, canTransfer, and getFrozenTokens](https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens)

Design implication (editorial): Label eligibility as context-dependent and refresh it at action time; a previously allowed state may change with block or caller context.

### getFrozenTokens MAY exceed an account's current balance, and an ERC-721 query MAY return true even when the account does not hold the token.

Applies to: application
Source classification: normative

> - `getFrozenTokens` will return the absolute frozen amount, which MAY exceed the account's current balance. In [ERC-721](./eip-721.md) tokens, it MAY return true even if the account does not hold the token.

Source: [Specification > canSend, canReceive, canTransfer, and getFrozenTokens](https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens)

Design implication (editorial): Show frozen amount and current balance as separate values, including future-withholding or tokenId-not-held states.

### forcedTransfer MAY bypass canTransfer; when it does, counted frozen assets MUST be unfrozen before the base transfer, and a Frozen event MUST be emitted.

Applies to: application
Source classification: normative

> - It MAY bypass the `canTransfer` checks. If this happens, and the transfer involves tokens that are currently counted as frozen, it MUST unfreeze the assets first and emit a `Frozen` event before the underlying base token transfer event reflecting the change. Having the unfrozen amount changed before the actual transfer is critical for tokens that might be susceptible to reentrancy attacks doing external checks on recipients, as is the case for [ERC-721](./eip-721.md) and [ERC-1155](./eip-1155.md) tokens.

Source: [Specification > forcedTransfer](https://ercs.ethereum.org/ERCS/erc-7943#forcedtransfer)

Design implication (editorial): Privileged-transfer review should disclose the bypass, the unfrozen amount change, and the resulting compliance status.

### Standard eligibility errors MAY be used as general reverts, MAY be replaced by more specific errors, or MAY be omitted.

Applies to: application
Source classification: normative

> The `ERC7943CannotSend`/`ERC7943CannotReceive`/`ERC7943CannotTransfer` errors MAY be used as a general revert mechanism whenever internal calls to `canSend`/`canReceive`/`canTransfer` return false. They MAY be replaced by more specific errors depending on the custom checks performed inside those calls, or simply not used.

Source: [Specification > Additional Specifications](https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications)

Design implication (editorial): Render the actual blocked reason from the implementation and avoid promising a particular selector or error label across all tokens.

### Specific errors SHOULD be thrown when applicable, including a distinct insufficient-unfrozen-balance condition.

Applies to: application
Source classification: normative

> In general, the standard prioritizes error specificity, meaning that specific errors such as `ERC7943InsufficientUnfrozenBalance` SHOULD be thrown when applicable. The `ERC7943InsufficientUnfrozenBalance` error SHOULD be triggered when a transfer is attempted from `account` with an `amount` less than or equal to its balance, but greater than its unfrozen balance, or with a `tokenId` which is currently frozen. If the `amount` is greater than the whole balance or the `tokenId` is not owned by the `account`, unrelated to the frozen amount, more specific errors from the base standard SHOULD be used instead.

Source: [Specification > Additional Specifications](https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications)

Design implication (editorial): Map specific errors to actionable copy such as frozen amount, insufficient unfrozen balance, or token ownership rather than a generic transfer failure.

### The standard separates account-level eligibility from transfer-level authorization and evaluates them independently.

Applies to: application
Source classification: rationale

> - **Separation of concerns**: The standard separates account-level eligibility (`canSend`, `canReceive`) from transfer-level authorization (`canTransfer`). `canSend` and `canReceive` evaluate whether an account is eligible to participate independently of any specific transfer parameters such as counterparty, amount, or token identifier. `canTransfer` evaluates whether a specific transfer is permissible under permissioned compliance rules, taking into account frozen balances, transfer limits, counterparty restrictions, and account eligibility. This separation provides clear semantics for integrators and avoids confusion between account eligibility and transfer-specific validation. It also enables one-way restrictions where an account may be blocked from receiving but still allowed to send, which is common in regulated environments.

Source: [Rationale](https://ercs.ethereum.org/ERCS/erc-7943#rationale)

Design implication (editorial): Keep account eligibility, counterparty, amount, tokenId, and transfer-policy checks visible as distinct reasons in a blocked or allowed state.

## Anti-Patterns (editorial)

- **Treating ERC-7943 as proof an asset is legally compliant** (critical)
  - Why: The interface exposes controls and checks but does not establish legal status, identity, or jurisdiction.
  - Instead: Show the actual policy, issuer evidence, and contract authority separately.

- **Showing total balance as transferable** (critical)
  - Why: Frozen amounts can be unavailable or exceed the current balance.
  - Instead: Display total, frozen, and current transferable values.

- **Assuming all ERC-7943 interfaces exist on every base token type** (high)
  - Why: The standard has separate fungible, non-fungible, and multi-token interfaces and implementations may support one or more.
  - Instead: Use ERC-165 detection and render only the supported interface.

- **Calling a forced transfer a user transfer** (high)
  - Why: Forced transfers use privileged access and can have different compliance semantics.
  - Instead: Give enforcement a distinct activity and authority presentation.

- **Caching eligibility as permanent** (medium)
  - Why: Policy, freeze, and recipient state can change between preflight and execution.
  - Instead: Refresh before submission and retain a pending/rejected recovery state.

## Design Decisions

### What does a blocked transfer reason say?

Recommendation: Use the implementation's specific error or policy result, then offer an issuer/support path; do not invent a KYC or legal reason.

Rationale: ERC-7943 defines decision surfaces, not a universal reason taxonomy or legal status.

### How should balances be displayed?

Recommendation: Show total, frozen, and transferable balance as separate values with a timestamp.

Rationale: The interface allows frozen amounts above current balance, so total balance alone is misleading.

### How should enforcement appear in history?

Recommendation: Use a distinct enforcement event style and identify the privileged actor and policy source.

Rationale: A forced transfer is not equivalent to a holder-initiated transfer and may bypass ordinary checks in some implementations.

## States to Design

### uRWA interface detected

Trigger: ERC-165 reports a supported ERC-7943 interface for the base token type.

User need: Know why this token has additional transfer states.

Design response: Show base token type, supported uRWA checks, policy source, and a restricted-asset notice without inventing legal claims.

### Transfer allowed

Trigger: canSend, canReceive, and canTransfer return true and base token checks pass.

User need: Know the transfer is eligible at the time of review.

Design response: Show transferable balance, policy timestamp, and the possibility that state may change before execution.

### Transfer blocked

Trigger: An eligibility check returns false or the base token rejects the operation.

User need: Understand which side or constraint prevented the transfer.

Design response: Show sender, recipient, amount/token ID, check result, and implementation-provided reason or support path.

### Partially frozen

Trigger: Frozen amount is below the current balance.

User need: Know how much can still move.

Design response: Show total, frozen, and current transferable amounts with an explicit refresh point.

### Fully or over-frozen

Trigger: Frozen amount meets or exceeds current balance, or a token ID is frozen.

User need: Know why a transfer or burn is unavailable.

Design response: Block the action and explain that future receipts may also be constrained until the freeze state changes.

### Privileged enforcement

Trigger: An authorized caller invokes forcedTransfer or setFrozenTokens.

User need: Understand the exceptional asset movement and its authority.

Design response: Show the actor, target, amount/token ID, policy evidence, event, transaction, and whether frozen balance was changed.

## Vocabulary

- Use "Transferable amount" instead of "Available balance": The remaining balance may still be locked by a policy or base-token rule.

- Use "Frozen by this token policy" instead of "Account banned": A frozen amount or transfer check does not by itself identify a person's legal status.

- Use "Forced transfer" instead of "Recovery transfer": The standard does not define why enforcement happened or guarantee that the recipient is a recovery address.

## UX Patterns

### Policy-Aware Transfer

Preflight the actual token's uRWA checks and show why an amount is transferable or blocked.

Components: Total/frozen/transferable balance, Eligibility result, Policy source, Refresh action

User flow:

- Detect base and ERC-7943 interface support
- Load frozen state and policy checks
- Enter recipient and amount/token ID
- Call canSend, canReceive, and canTransfer
- Show allowed or blocked review
- Recheck before submission

### Enforcement Activity Record

Give freeze and forced-transfer events a distinct, auditable presentation.

Components: Authority badge, Frozen-state delta, Forced-transfer label, Policy/evidence links

User flow:

- Receive an event or transaction
- Identify actor and target
- Read amount/token ID and freeze delta
- Open policy or issuer evidence
- Update balances and transfer availability

## What to Prototype First

### Restricted-token transfer review

A familiar transfer form must communicate that eligibility and frozen balance can change the result.

Covers: Allowed transfer, Sender blocked, Recipient blocked, Frozen amount exceeds available

- Base token type
- Transferable and frozen balances
- canTransfer result
- Policy source
- Retry after refresh

### Enforcement and freeze activity

A privileged action changes asset mobility and may carry legal or operational consequences.

Covers: Freeze set, Freeze lifted, Forced transfer, Unauthorized action

- Authority identity
- Amount or token ID
- Event and transaction links
- Policy evidence
- Audit trail

## Mental Model

### Base token

ERC-7943 extends a base token such as ERC-20, ERC-721, ERC-1155, or ERC-6909; base ownership and balance semantics still apply.

### Eligibility check

canSend, canReceive, and canTransfer expose the implementation's current policy decision without changing state.

### Frozen amount

getFrozenTokens reports an absolute frozen amount, which can exceed the current balance and can make future receipts unavailable.

### Enforcement authority

forcedTransfer and setFrozenTokens require restricted access chosen by the implementation; the interface does not identify the legal or governance authority.

### Policy change

A transfer can become unavailable when policy or freeze state changes, so a prior quote or check is not a permanent authorization.

## UI Components

### TransferabilityBreakdown

Separates base balance or ownership from frozen and currently transferable amounts.
Kind: list
States: loading, transferable, partially-frozen, fully-frozen, policy-blocked, unsupported
Props: tokenType, account, tokenId, balance, frozenAmount, canSend, canReceive, canTransfer

### EnforcementEventRow

Marks freeze and forced-transfer actions with actor, target, evidence, and state changes.
Kind: status
States: frozen, unfrozen, forced-transfer, unknown-authority, pending
Props: eventType, actor, account, amount, tokenId, transactionHash, policySource

## Key Takeaways

- ERC-7943 standardizes compliance checks and enforcement surfaces, not legal meaning or wallet support.
- Show total, frozen, and transferable values separately.
- Feature-detect the supported base-token interface and recheck policy before execution.
- Give privileged freeze and forced-transfer actions a distinct audited presentation.

## Related Standards

- ERC-20: Fungible base token that can be extended by the ERC-7943 fungible interface. — https://www.eipsfordesigners.com/standards/ERC-20/agent.md

- ERC-721: Non-fungible base token that can expose per-token frozen and eligibility state. — https://www.eipsfordesigners.com/standards/ERC-721/agent.md

- ERC-1155: Multi-token base interface supported by the ERC-7943 multi-token variant. — https://www.eipsfordesigners.com/standards/ERC-1155/agent.md

- ERC-3643: A broader permissioned-token implementation reference whose policy and identity model must remain distinct from ERC-7943. — https://www.eipsfordesigners.com/standards/ERC-3643/agent.md

## Technical Notes

ERC-7943 defines ERC-20, ERC-721, and ERC-1155 interfaces (and a multi-token variant) with canSend, canReceive, canTransfer, getFrozenTokens, forcedTransfer, and setFrozenTokens surfaces. Implementations must advertise the appropriate ERC-165 interface ID and enforce transfer restrictions through the base token operations. Frozen amounts are absolute and may exceed current balances. forcedTransfer and setFrozenTokens must be access-controlled, but the standard does not mandate an authority model, legal reason, policy registry, or specific error taxonomy. Full uRWA support requires explicit integration.

## Official specification (reference only)

https://ercs.ethereum.org/ERCS/erc-7943