ERC-7943: Universal RWA Interface (uRWA)

ERCs
29

Hi everyone,

Before diving into details, I’d like to understand the core goals of this new ERC-7943 proposal:

  1. What specific use-cases or capabilities would uRWA enable that ERC-3643 today cannot?
  2. Which pain-points in existing RWA implementations motivated a completely separate interface rather than an extension or variant of ERC-3643?

Standards exist to avoid fragmentation, not to multiply overlapping interfaces for the same problem domain. ERC-3643 already provides:

  • On‐chain compliance hooks (isVerified / canTransfer) that map directly to real-world identity and regulatory rules
  • Permissioned minting, forced transfers and freezing (forceTransfer, freeze, etc.)
  • ERC-165 introspection and a growing ecosystem of bridges, wallets, custodians and institutional platforms

We’ve seen wallet-level whitelist approaches before (e.g. ERC-1400 and other “whitelist only” token interfaces), and they fall short because compliance rules live at the identity level, not at the wallet level. One end-user frequently controls multiple addresses. How would you enforce Reg D’s “max investors per country” or MiFID’s product eligibility checks without an identity concept baked into the standard?

Moreover, ERC-3643 is already supported by a broad suite of Web3 players and regulated institutions. Splitting out a near-duplicate interface risks diluting integration effort, confusing tooling, and ultimately slowing RWA on-chain adoption. The real value isn’t in more standards, but in uniting around one that’s proven, audited, and battle-tested.

If the concern is that ERC-3643 is too “big” or opinionated, let’s collaborate on modular, optional extensions rather than renaming the same core functions:

  • Why use isUserAllowed instead of the existing isVerified?
  • Why isTransferAllowed instead of canTransfer, which already appears in 3643 (and historically in ERC-1400)?

On the NFT (ERC-721) and multi-token (ERC-1155) side, you can absolutely reuse the ERC-3643 compliance layer via lightweight adapter contracts or a secondary “compliance” interface. This could be formalized later as its own ERC, but it isn’t what’s proposed here.

In short:

  • Let’s avoid fragmenting the ecosystem with several standards serving the same purpose.
  • ERC-3643 already covers the full spectrum of RWA compliance and control.
  • If there’s genuine innovation such as new functions, on-chain identity primitives, radically different security models; please outline them and let’s fold them into the existing 3643 workstream.

We’re actively maintaining and extending ERC-3643 with industry partners and would welcome anyone who cares about RWA tokenization to join forces, not fork.

Looking forward to your thoughts!

5 Likes