ERC-7943: Universal RWA Interface (uRWA)

xaler · July 31, 2025, 10:35am

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 ?

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