ERC-7943: uRWA - Universal Real World Asset Interface

Interfaces for common base tokens defining compliance checks, transfer controls, and enforcement actions for Real World Assets (RWAs).

Metadata

Status: ReviewStandards Track: ERCCreated: 2025-06-10

Authors

Dario Lo Buglio (@xaler5)

Requires

EIP-165

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This EIP proposes the Universal RWA (uRWA) standard, a set of interfaces for tokenized Real World Assets (RWAs) such as securities, real estate, commodities, or other physical/financial assets on the blockchain.

Real World Assets often require regulatory compliance features not found in standard tokens, including the ability to freeze assets, perform enforcement transfers for legal compliance, and restrict transfers to authorized users. The uRWA standard extends common token standards like ERC-20, ERC-721 or ERC-1155 by introducing essential compliance functions while remaining minimal and not opinionated about specific implementation details.

This enables DeFi protocols and applications to interact with tokenized real-world assets in a standardized way, knowing they can check transfer permissions, whether users are allowed to interact, handle frozen assets appropriately, and integrate with compliant RWA tokens regardless of the underlying asset type or internal compliance logic. It also adopts ERC-165 for introspection.

Motivation

Real World Assets (RWAs) represent a significant opportunity to bridge traditional finance and decentralized finance (DeFi). By tokenizing assets like real estate, corporate bonds, commodities, art, or securities, we can unlock benefits such as fractional ownership, programmable compliance, enhanced liquidity through secondary markets for traditionally illiquid assets and integration with decentralized protocols.

However, tokenizing real world assets introduces regulatory requirements often absent in purely digital assets, such as allowlists for users, transfer restrictions, asset freezing, or law enforcement rules. Existing token standards like ERC-20, ERC-721 and ERC-1155 lack the inherent structure to address these compliance needs directly within the standard itself.

Attempts at defining universal RWA standards historically imposed unnecessary complexity and gas overhead for simpler use cases that do not require the full spectrum of features like granular role-based access control, mandatory on-chain whitelisting, specific on-chain identity solutions, or metadata handling solutions mandated by the standard.

Additionally, the broad spectrum of RWA classes inherently suggests the need to move away from a one-size-fits-all solution. With the purpose in mind of defining an EIP for it, a minimalistic approach, unopinionated features list, and maximally compatible design should be kept in mind.

The uRWA standard seeks a more refined balance by defining an essential interface, establishing a common ground for interaction regarding compliance and control, without dictating the underlying implementation mechanisms. This allows core token implementations to remain lean while providing standard functions for RWA-specific interactions.

The final goal is to build composable DeFi around RWAs, providing the same interface when dealing with compliance and regulation.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

The following defines the standard interfaces for an ERC-7943 token contract, which MUST extend from one base token interface such as ERC-20, ERC-721 or ERC-1155:

`canTransact`, `canTransfer` and `getFrozenTokens`

These provide views into the implementing contract's compliance, transfer policy logic and freezing status. These functions:

MUST NOT revert.
MUST NOT change the storage of the contract.
MAY depend on context (e.g., current timestamp, block number or msg.sender).
The canTransfer 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). Additionally it MAY perform a canTransact check on the from and to parameters. An important documentation note is that ERC-3643 doesn't perform a canTransact check within canTransfer as optionally suggested.
canTransfer should return false if the contract is paused.
getFrozenTokens CAN return an amount higher than the user’s balance due to setFrozenTokens allowing to freeze tokens exceeding account's holdings. In ERC-721 tokens, it CAN return true even if the account does not hold the token.

`forcedTransfer`

This function provides a standard mechanism for forcing a transfer from a from to a to address. The function:

MUST directly manipulate balances or ownership to transfer the asset from from to to either by transferring or burning from from and minting to to.
MUST be restricted in access.
MUST perform necessary validation checks (e.g., sufficient balance/ownership of a specific token).
MUST emit both the standard transfer event (from the base standard) and the ForcedTransfer event.
It CAN bypass the freezing validations and update the freezing status accordingly. Only if this happens, 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 it is the case for ERC-721 and ERC-1155 tokens.
MUST bypass checks enforced by canTransfer.
it SHOULD perform a canTransact check on the to parameter.

`setFrozenTokens`

It provides a way to freeze or unfreeze assets held by a specific account. This is useful for temporary lock mechanisms. This function:

MUST emit the Frozen event.
MUST be restricted in access.
SHOULD allow freezing more assets than those held. This allows for future balances withholding.

Additional Specifications

The contract MUST implement the ERC-165 supportsInterface function and MUST return true for the bytes4 value (representing the interfaceId):

0x29388973 for the fungible interface.
0xa8fdc849 for the non-fungible interface.
0x5627c61a for the multi token interface.

Implementations of these interfaces MUST implement the necessary functions of their chosen base standard (e.g., ERC-20 for the fungible interface, ERC-721 for the non fungible interface and ERC-1155 for the multi token interface) and MUST also restrict access to sensitive functions like forcedTransfer and setFrozenTokens using an appropriate access control mechanism (e.g., onlyOwner, Role-Based Access Control). The specific mechanism is NOT mandated by this interface standard.

Implementations MUST ensure their transfer methods exhibit the following behavior:

Public transfers (transfer, transferFrom, safeTransferFrom, etc.) MUST NOT succeed in cases in which canTransfer or canTransact would return false for either one or both from and to addresses.
Minting MUST NOT succeed to accounts where canTransact on the recipient would return false.
Burning SHOULD NOT be restricted by canTransfer or canTransact checks on the token holder. It MAY be restricted to prevent burning more assets than the unfrozen amount (e.g., in public burning functions). It MAY burn more assets than the unfrozen amount (e.g., in permissioned burning functions), in which case the contract MUST update the frozen status accordingly and emit a Frozen event before the underlying base token transfer event.

The ERC7943CannotTransact/ERC7943CannotTransfer errors CAN be used as a general revert mechanism whenever internal calls to canTransact/canTransfer return false. They MAY NOT be used or MAY be replaced by more specific errors depending on the custom checks performed inside those calls.

In general, the standard prioritizes error specificity, meaning that specific errors such as ERC7943InsufficientUnfrozenBalance/ERC7943FrozenTokenId SHOULD be thrown when applicable. The ERC7943InsufficientUnfrozenBalance/ERC7943FrozenTokenId 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 from the frozen amount, more specific errors from the base standard SHOULD be used instead.

Rationale

Minimalism: Defines only the essential functions (forcedTransfer, setFrozenTokens, canTransact, canTransfer, getFrozenTokens) and associated events/errors needed for common RWA compliance and control patterns, avoiding mandated complexity or opinionated features. The reason to introduce specific errors (ERC7943CannotTransact, ERC7943CannotTransfer and ERC7943InsufficientUnfrozenBalance) is to provide completeness with the introduced functionalities (canTransact, canTransfer and getFrozenTokens). As dictated in the specifications, error specificity is prioritized, leaving space for implementations to accommodate more explicit errors. Regarding the events Frozen and ForcedTransfer, the reason for their existence is to signal uncommon transfers (like in forcedTransfer) but also to help off-chain indexers to correctly keep track and account for asset seizures and freezing. As mentioned in the specifications, special attention should be paid to the order in which these events are emitted in relation to the base token contract events.
Flexible compliance: Provides standard view functions (canTransact, canTransfer, getFrozenTokens) for compliance checks without dictating how those checks are implemented internally by the token contract. This allows diverse compliance strategies.
Compatibility: Designed as an interface layer compatible with existing base standards like ERC-20, ERC-721 and ERC-1155. Implementations extend from ERC-7943 alongside their base standard interface. Additionally, with the adopted naming conventions, automatic backward compatibility is achieved with already existing standards like ERC-3643 and ERC-7518.
Essential enforcement rules: Includes forcedTransfer and setFrozenTokens as standard functions, acknowledging their importance for regulatory enforcement in the RWA space, distinct from standard transfers. Mandates access control for this sensitive function. To maintain a lean EIP, a single setFrozenTokens function (which overwrites the frozen asset quantity) and one Frozen event were favored over distinct freeze/unfreeze functions and events.
ERC-165: Ensures implementing contracts can signal support for this interface.

As an example, an AMM pool or a lending protocol can integrate with ERC-7943 based ERC-20 tokens by calling canTransact or canTransfer to handle these assets in a compliant manner. Enforcement actions like forcedTransfer and setFrozenTokens can either be called by third party entities or be integrated by external protocols to allow for automated and programmable compliance. Users can then expand these tokens with additional features to fit the specific needs of individual asset types, either with on-chain identity systems, historical balances tracking for dividend distributions, semi-fungibility with token metadata, and other custom functionalities.

Extensibility

While this ERC provides the necessary primitives for regulated assets, any additional feature can be added through extensions. As an example, if for any administrative function like setFrozenTokens a valid legal proof must be provided and attached to the call, the contract can have a function that batches operations like:

Alternatively, developers can also perform several operations through the use of multicall patterns similar to the one defined in ERC-6357 so that a mix of the given primitives with additional features can be batched in one transaction. Finally, functionalities like pausability can be added on top, either through the use of modifiers or directly within functions implementations.

Notes on naming

The naming conventions in this ERC were carefully chosen to establish clarity and semantic consistency within the broader RWA ecosystem while maintaining neutrality and broad applicability.

forcedTransfer: This term was selected for its neutrality. While names like confiscation, revocation, or recovery describe specific motivations, forcedTransfer purely denotes the direct action of transferring assets, irrespective of the underlying reason. forcedTransfer was preferred over forceTransfer to maintain backward compatibility with ERC-3643.
canTransfer: This name was preferred over isTransferAllowed for consistency with established RWA standards including ERC-3643 and ERC-7518. This alignment promotes interoperability and reduces cognitive overhead when working across different RWA tokens.
setFrozenTokens / getFrozenTokens: These names were chosen for managing transfer restrictions and align with ERC-3643 naming patterns. Frozen was also selected for its general applicability to both fungible (amount-based) and non-fungible (status-based) assets, as terms like amount or asset(s) might not be universally fitting.
ERC7943InsufficientUnfrozenBalance: Discussions around insufficient being similar to unavailable arose, where unavailable might have better suggested a temporal condition like a freezing status. However, the term available/unavailable was also overlapping with frozen/unfrozen creating more confusion and duality. Finally, coupling insufficient with the specified unfrozen balance better represents the domain, prefix and subject of the error, according to ERC-6093 guidelines.

Backwards Compatibility

This EIP defines a new interface standard and does not alter existing ones like ERC-20, ERC-721 and ERC-1155. 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 canTransact, canTransfer and getFrozenTokens functions. Full support for the ERC-7943 functions requires explicit integration.

Reference Implementation

Reference implementations of uRWA for ERC-20, ERC-721 and ERC-1155 token implementations is provided in assets folder. They use the OpenZeppelin library and include an account whitelist and enumerable role-based access control. These examples are provided for educational purposes only and are not audited.

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-run of the setFrozenTokens function: The setFrozenTokens function might be susceptible to front-running, similar to the approve function of the ERC-20. If the suggestion of allowing freezing more than what an account owns is not followed, a front-run might be an incentive to an account to avoid any attempt of freezing its balance. Additional features to gradually increment or decrement the frozen status CAN be considered for implementation.
Implementation Logic: The correctness of the implementation behind all interface functions is critical. Flaws in this logic could bypass intended transfer restrictions or incorrectly block valid transfers.
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 like in ERC-721 or ERC-1155. In such circumstances it might be convenient to adopt reentrancy guards to prevent unwanted executions.