ERC-7943: Universal RWA Interface (uRWA)

[mihaic195]

Hello everyone,

This proposal clearly states that EIP-7943 deliberately omits metadata handling and focuses more on compliance and enforcement. Great work keeping the interface minimal.

I chatted with @davrilio about the document management aspect (outside of this thread).

Although I understand how this document storage can be viewed as metadata handling or something optional, it can be a core token component, linking the real-world asset with the token itself. While this is more common for security tokens, it could be valuable for Asset-Referenced Tokens (ART) regarding MiCA compliance (I’m not a legal expert). It can be used to prove to investors that the prospectus hasn’t changed and that it’s the same one that regulators approved.

The question is whether we want to implement this as part of the original standard or as an extension/independent modular component on top of EIP-7943.

@davrilio

We could for example think of adding a URI link to an external data source. Such mechanism exists, for example in ERC-721 or ERC-1155 but not without problems. The mutable nature of such attribute should be very carefully managed in order to avoid cases where updates might lead to tokens that point to wrong URIs or even intentional manipulations of the token that could lead to rug-pulls or other scams. Also, the off-chain/on-chain bridge is a rather complicated topic that, if we try to solve together with the token ownership, rights, permissions, etc. might lead to complex smart contract logic, i.e. code that is difficult to maintain and make evolve.

ERC20 can be extended with ERC1046 to provide the tokenURI() extension similar to ERC721/ERC1155, but this approach might be opinionated.

I believe EIP1643 already solves this problem. Even though it hasn’t been officially adopted as a standard, it has been battle-tested by CMTAT and other ERC1400 implementations, so I don’t see why we need to reinvent the wheel.

From a technical standpoint, with EIP1643, you can attach multiple documents because it stores a bytes32 document hash (e.g., a Merkle root aggregating IPFS CIDs), so one hash covers many docs.

If immutability or upgradeability is a concern, you can always make it immutable or extend EIP1643 with some lockable/governance mechanism. I think this is why the original authors of EIP1643 didn’t implement this, leaving it to implementors to decide based on the use case.

So, maybe I’d keep EIP-7943 untouched and reference EIP-1643 (or an evolution of it) in a separate module, leaving it customizable as required.

[davrilio]

Good point about EIP-1643. The handling of a Hash (associated to a document or as a root of a Merkle tree being associated to many documents) is one part of the problem. I believe a link to a RWA that can be added or removed is not enough though as there is no logical update of the document, not even a way to check whether the hashes are versions of the same document or completely disconnected things. In a sense, this is ok because EIP-1643 doesn’t convey any semantics on the hashes, on the other side for compliance you may want to maintain audit trails, etc. In any case the point is that the logic for implementing all these things should be IMO outside EIP-7943, and my point was that the computational element that manages this logic should be a smart contract on-chain and not a URI or a hash. In that way the AssetReference related to an EIP-7943 token is also on-chain so for traceability reasons one can follow what processing and logic is behind the AssetReference.

[ivanmmurcia]

Thanks for this proposal guys. I’m not a big fan of adding freezing mechanisms in a standard, I’m more of delegating such dirty actions to other actors/modules as the implementation of Distributed Labs demonstrates

[xaler]

Hello @ivanmmurcia and thanks for your comment.

Can you provide more arguments of why you prefer one way or the other ? Is there any important legit use case that really don’t need that feature ? As of my understanding, in regulated environments, it’s a pretty much needed feature indeed, justifying why it should stay in the standard.

Additionally I gave a quick look at your implementation, I’m not really sure but as far as I see:

• It uses a diamond like structure
• Modules are exclusively read-only features ? If not, how is storage changes handled ? Are modules directly called with an external call or using delegate ones ?

I have been exploring the same exact architecture and while I believe is a powerful one, it present some limitations which are not easy to handle with:

• Diamond is not the most simple (and not yet widely supported) design solution, it solves the size limits but it really complicates flows and manteinance, not really suitable for simple use cases. Additionally, while diamond inherently enables features-extension, it does not extend the interface itself as a normal inheritance design would do, and this might present some tradeoffs with offchain integrations.
• Storage changes through modules, having only read-only modules is kind of limiting, while having modules to change the state present the need to decide which context should be used to store the changes (I see you adopted a namespaced storage pattern, that would imply that delegatecalls to modules can safely change the state of the calling contract but bringing even delegate call into the design brings also some security considerations).

Either way, this might be off topic. In summary:

I believe there are strong reasons to believe that freezing should stay in the main interface, but I’m happy to listen to any additional argument beoynd the implementation itself of the feature.

Again thanks for the time taken to review this so far

[xaler]

Thanks @davrilio and @mihaic195 for the interesting conversations about the metadata handling.

I agree with both:

• This to me is something orthogonal to 7943 and it’s definetely compatible through inclusion. As you mentioned, you can go even beyond that and enforces specific metadata rules to be applied in functions like isTransferAllowed or isUserAllowed).

• The idea of EIP-1643 sounds nice. On the “mutability” issue mentioned and the need for a more robust solution to ensure untampered metadata I’ve been recently reading about new patterns emerging as @mihaic195 mentioned (hash-chained root of the whole state of metadata, merkle tree solutions, and I wouldn’t be surprised to start seeing more zero knowledge related work to better fit into privacy conserving contexts).

[xaler]

Hello folks !

I’ve been thinking a bit more and doing some extra research and I ended up finding two additional EIPs which are interesting for the current scope:

• EIP-7751 ERC-7551: Crypto Security Token Smart Contract Interface ("eWpG"). Curiously some discussion about ERC-3643 and OnchainID is also present in that thread and that EIP is similar in having freezing/force transfers. I like the fact that terminology seems to align (and also basic features).
• EIP-7518 ERC-7518: Dynamic Compliant Interop Security Token. This EIP also have similar features but implements also a payout feature which i don’t believe is essential for all RWAs.

At this point I have several thoughts:

• isTransferAllowed can be renamed to canTransfer to align with 3643, 7751 and 7518.
• It appear that pausability is present in almost all of similar other EIPs. Still I’m in not fully confident in adding it to the EIP because it would come with more challenges like what paused token means ? all transfers / mint / burn are paused or only one of them ? What about approvals or other features the token might have (yield, rebalances, voting … ) ? Additionally, there’s still a bit of overlap with isTransferAllowed and isUserAllowed where pausability can be implemented.
• About metadata handling, it also seems to be a recurrent topic accross several EIPs but as stated before I’m in favor of creating an example plugin for 7943 in the reference implementation repository.
• freeze/unfreeze seems preferred in other EIPs, but we already addressed why we use setFrozen / getFrozen in the “Notes on naming” paragraph. Do you think it is sufficient ?
• Other EIPs implement an account-based freezing (different from the current balance-based freezing mechanism) where accounts are frozen by their address and not by their assets. While I believe this is interesting, I think it overlaps with isUserAllowed and that there’s no need for a specific extra feature to cover for it. What are your thoughts ?

Also, based on feedback received on a potential implementation for OpenZeppelin community contracts library (Add ERC20Freezable, ERC20Restricted and ERC20uRWA by ernestognw · Pull Request #186 · OpenZeppelin/openzeppelin-community-contracts · GitHub)

• ERC7943NotAllowedTransfer seems to be useless in terms of implementation since it’s not specific and most of the time a more explicit error will preceed. The EIP defines already the optionality of this error, but wondering if it’s worth at all at this point.

cc @ernestognw in case you want to provide more feedback

[xaler]

I’ve also added some examples in the reference implementation on how to integrate:

• Multicall
• Pausability
• EIP-1643 like metadata handling

uRWA/contracts/modules/erc20 at master · xaler5/uRWA

[diegoebasta]

Congrats on your effort; AI analyzed the proposal and said this:

## 1. Summary

ERC-7943 defines a minimal interface to introduce on-chain compliance controls—freezing, forced transfers, and allowlist checks—on top of any base token (ERC-20/721/1155) while preserving composability via ERC-165 introspection.

---

## 2. Strengths

1. Minimal, Non-Opinionated Design

• Only five new functions plus matching events/errors, avoiding the “kitchen-sink” approach of prior RWA EIPs.
• Leaves implementation details (whitelisting, role management, identity backends) entirely to integrators, reducing gas overhead for simple use-cases.

2. Unified Across Standards

• One interface covers fungible, non-fungible, and semi-fungible assets, with clear guidance on using tokenId = 0 or amount = 1 for ERC-20/721 respectively.
• Leverages ERC-165 so wallets and tooling can detect RWA-capable tokens at runtime.

3. Explicit Error Semantics

• Introduces three bespoke errors (ERC7943NotAllowedUser, …NotAllowedTransfer, …InsufficientUnfrozenBalance), improving on generic “revert” messages and helping integrators handle compliance failures programmatically.

4. Enforcement Hook

• forceTransfer provides a standardized way to implement on-chain asset recovery or regulatory seizure, complete with event ordering rules to aid indexers.

---

## 3. Weaknesses & Open Questions

1. Access Control Unspecified

• While deliberate, the lack of any recommendation (e.g. using OpenZeppelin’s AccessControl) means some implementations may insecurely gate forceTransfer/setFrozen. A “recommended practice” section could help.

3. Batch Operations for 1155

• Freezing and forced-transfer APIs are single-token only. High-volume 1155 use-cases (e.g. real-world commodity baskets) might need batch versions to avoid repetitive gas costs.

4. No On-chain Auditing Hooks

• Aside from the two events, there’s no mechanism to record why an address was disallowed or frozen. An optional “reason” string or a getFreezeReason(user, tokenId) view could aid transparency.

Interplay with ERC-1404/1400

• Prior EIPs (e.g. the security-token ERC-1404) also tackled allowlists and transfer checks. A brief “Compatibility” section comparing uRWA to those could help implementers choose the right standard.

---

## 4. Suggestions

Add a “Recommended Access Control” Annex:

Propose a minimal RBAC pattern (e.g. an ENFORCER_ROLE) so newcomers avoid mis-configuring permissions.

Introduce Optional Batch APIs:

Two additional functions:

function setFrozenBatch(address user, uint256[] tokenIds, uint256[] amounts) external;
function forceTransferBatch(address from, address to, uint256[] tokenIds, uint256[] amounts) external;

These can be “MAY” rather than “MUST,” preserving minimalism.

Define “Reason Codes”:

Extend the Frozen event (or add a companion) to carry a short bytes32 reasonCode so off-chain systems can track compliance workflows.

Clarify Edge Cases:

For example, should forceTransfer on a non-existent ERC-721 token revert with the same errors as a standard transfer? A bullet in “Security Considerations” would tighten the spec.

---

## 5. Conclusion

ERC-7943 strikes a solid balance between “just enough” compliance tooling and base-token simplicity. It’s flexible enough to cover most RWA scenarios, yet lightweight relative to full security-token frameworks. With a few minor enhancements around access control guidance, batch operations, and auditability, I believe it can become the go-to standard for tokenized real-world assets.

[mihaic195]

Hey @xaler,

Thanks for the update!

Although we see many similarities in functionality regarding ERC-7551, I think the motivation was to have something without the ONCHAINID component and aligned with the German electronic securities law (eWpG). However, I haven’t seen major developments since it was opened in 2023.

I hadn’t encountered ERC-7518 before. It looks like an extension to ERC-1155, specifically regarding partitions. ERC-1400 already popularized the concept of tranches/partitions. ERC-7943 can already extend ERC-1155, as seen in your examples repo.

Terminology-wise, renaming isTransferAllowed to canTransfer makes sense to better align with what already exists.

@davrilio and I had a fruitful conversation about handling metadata and exchanged ideas. We often see opinionated versions of this and implementations specific to each use case. Decoupling it from the token contract and simply providing a reference could make sense. Hopefully, @davrilio and I can collaborate on something soon.

Thinking about pausability, I’m looking at OZ’s ERC20Pausable NatSpec comments:

/**

* @dev ERC-20 token with pausable token transfers, minting and burning.

*

* Useful for scenarios such as preventing trades until the end of an evaluation

* period, or having an emergency switch for freezing all token transfers in the

* event of a large bug.

*

It overrides the _update function, which is common to all of these functionalities (transfer/mint/burn). Since it’s an “emergency switch,” I think it’s irrelevant for the other functionalities you mentioned, only for critical ones that explicitly change balances/supply. The different functionalities (approvals, yield, rebalances, voting, etc.) are highly coupled with transfers, so pausing those is redundant in theory.

Maybe this will help you better decide whether to include it as part of the EIP.

One useful improvement I could suggest is in regards to the event in the interface:

Change from

event ForcedTransfer(address indexed from, address indexed to, uint256 tokenId, uint256 amount);

to

event ForcedTransfer(address indexed from, address indexed to, uint256 indexed tokenId, uint256 amount);

In the context of NFT-style assets, regulators, custodians, or UIs usually care much more about “show me the forced transfers for token #1234”. You already index it on the Frozen event.

[ernestognw]

Hi @xaler! Some thoughts in response:

• isTransferAllowed can be renamed to canTransfer to align with 3643, 7751 and 7518.

I would 100% agree with this. I don’t think changing the name of this function is a deal breaker and it’s a good opportunity to align interface-wise. There are projects that want certain level of compatibility with 3643 and imo this is in the right direction.

It appear that pausability is present in almost all of similar other EIPs.

I wouldn’t include it. I see little benefit in adding pausability to a standard. At the end, this is a feature that allows the team behind a token to react to security incidents, so under “normal operation” pausability shouldn’t be even perceived by the end user.

I would say protocol security teams would decide how (and to what degree) pause their systems, and the uRWA spec is not the place to enforce that. Also, it raises weird questions about isTransferAllowed and isUserAllowed as you pointed out. Imo, the best we can do to specify what those functions should do is speculate until we see a couple of pausable RWA in the wild.

Do you think it is sufficient ?

I think it’s sufficient. Perhaps I would mention increaseAllowance and decreaseAllowance in ERC20s that was never really used although it theoretically fixed a frontrunning issue. See this issue

ERC7943NotAllowedTransfer seems to be useless in terms of implementation since it’s not specific and most of the time a more explicit error will preceed.

I ended up removing it from the community contracts implementation. Here’s the rationale: Add ERC20Freezable, ERC20Restricted and ERC20uRWA by ernestognw · Pull Request #186 · OpenZeppelin/openzeppelin-community-contracts · GitHub

I would consider removing the error altogether. The main reason is that it’s not specific and there seems to be always a more specific replacement for it.

[ariutokintumi]

gm, great work @xaler!

I noticed @tinom9’s thoughtful discussion on the forceTransfer behavior, especially regarding the handling of a token’s potential frozen state. One point that seems crucial but currently missing from the discussion is explicitly addressing whether tokens should remain frozen or become unfrozen after a forced transfer.

I believe it’s essential that a token maintains its original frozen/unfrozen state after being forcefully transferred, independent of the transfer itself.

To illustrate this, consider a legal scenario: a court could mandate transferring tokens from party A to party B due to ongoing litigation, but simultaneously restrict party B’s ability to use or dispose of the tokens until the case is resolved (effectively allowing use but not possession). Automatically unfreezing tokens upon forced transfer would bypass this critical legal step and potentially undermine compliance.

While I’m not a lawyer and there are likely many nuanced cases, intuitively, it seems safer and more legally sound to separate these two actions clearly. Unfreezing a token should ideally be a distinct subsequent step, explicitly authorized and handled separately, rather than implicitly assumed.

Curious to hear your thoughts on this!