Hey @Joachim-Lebrun thanks for joining the conversation and providing inisights and concerns.
I believe the draft of the EIP answers already all your questions but I’ll try to expand below touching on several points.
Which pain-points in existing RWA implementations motivated a completely separate interface rather than an extension or variant of ERC-3643 ?
ERC-3643’s architecture of many different interfaces introduces complexity that may not be necessary for all RWA use cases. uRWA provides essential compliance primitives (user validation, transfer checks, asset freezing, forced transfers) without requiring specific identity or compliance architectures.
Through discussions with various builders in the RWA space, I’ve observed a pattern where comprehensive standards attempt to address every possible use case. While thorough, this approach can result in implementation challenges for projects with simpler requirements and has the risk of inherently introducing opinionated designs, features and frictions on implementers.
Since you mentioned not adhering to EIP-1, from it we can read:
The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.
I don’t believe ERC-3643 is concise and I believe is also having a jeopardized consensus in the community, this is indeed highlighted in many comments in the ERC-3643 Ethereum Magician thread ( 1, 2 ). Looking at historical conversation I believe ERC-3643 went to finalized before gathering broad builders consensus and here we are trying to fix this.
- ERC-3643’s architectural coupling with specific compliance and identity structures may limit flexibility for diverse use cases.
- Features like transaction batching have been superseded by more flexible patterns like Multicall,
- As evident from discussions in this thread, features like pausability, minting, and burning may not be fundamental requirements for every RWA implementation.
The ecosystem would benefit from a more modular foundation that serves as a building block for various RWA implementations. Regarding the fact that uRWA doesn’t bring anything new violating EIP-1 I must disagree, reason on next point below.
What specific use-cases or capabilities would uRWA enable that ERC-3643 today cannot ?
uRWA extends support to ERC-721, ERC-1155, and derived standards. RWAs encompass more than fungible assets, and a comprehensive and future-proof standard should accommodate this diversity. Implementing multiple token standards through a unified interface significantly reduces integration complexity compared to creating separate ERC-3643 extensions for each token type.
While ERC-3643 could theoretically be extended for other token standards, its specification states “MUST be an ERC-20,” indicating this wasn’t the original design intent. Each extension would require separate standardization efforts, whereas uRWA addresses this through a single, unified interface.
Previous motivation also implies a re-work of this from the ground, not only to include new use cases, but to build a modern playground for every builder, company or institution to have their specific needs and flows fulfilled.
In short, not only it introduces a broader compatibility that ERC-3643 doesn’t have, but it also has a completely different base that allows flexible implementations. I believe this is sufficient to make 7943 fundamentally different from 3643.
Standards exist to avoid fragmentation, not to multiply overlapping interfaces for the same problem domain. ERC-3643 already provides:
Innovation and improvement or even replacements of existing standards is a natural part of the standardization process. While I agree that standards should prevent fragmentation I also recognize that they also need to be lean, minimal, and future-proof in a fast changing environment of regulations and institutional requirements.
In this regard I agree with @ernestognw here, calling out 7943 for fragmenting is unfair. On the contrary 7943 tries to fix what 3643 was not able to address. Fragmentation is not necessarily having multiple standards for the same domain; over specifying a standard with a a high number of interfaces also increases fragmentation.
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?
This raises important architectural questions. Regulations typically define what must be enforced (e.g. investor limits, jurisdictional access, eligibility) but don’t prescribe how that enforcement should be implemented technically.
Identity verification and permissioning can be handled in multiple ways, fully off-chain (via KYC providers), partially on-chain (via attestations or registries), or fully on-chain (via role-based contracts or ZK proofs).
What EIP-7943 introduces is an interface standard that accommodates all these models. It does not assume a single enforcement path but rather provides hooks (isUserAllowed, isTransferAllowed) for integrating any compliance mechanism, whether centralized or decentralized.
Your question about Reg D and MiFID is an important one, especially around how legal identity and enforcement thresholds are interpreted across jurisdictions. Tagging @EdwinMata here to expand on how these frameworks treat identity, and whether EIP-7943’s architecture meets legal sufficiency under existing global regulations.
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.
I don’t know what you mean by “proven, audited, and battle-tested” but to me, what’s in need of being proven, tested and audited is the implementation of the standard, not the standard itself.
My research indicates that several projects have opted for custom implementations rather than adopting ERC-3643, which suggests there may be accessibility or complexity considerations. Regarding the ecosystem support you mentioned, could you help clarify:
- Are there ERC-3643 open source implementations beyond the Tokeny reference implementation?
- What is the total value locked in ERC-3643 compliant tokens outside the ones using the Tokeny implementation?
That should help in framing how ERC-3643 might be deeply coupled with the implementation of one company. Standards should leave freedom to implementers. Diverse implementations are key for security.
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:
Extensions of ERC-3643 would inherit its complete architecture, which wouldn’t address the core concern about modularity. So not sure how ERC-3643 can be reused to address these concerns.
Regarding function naming compatibility, it is certainly worth exploring to minimize ecosystem fragmentation. I’m up for revisiting things around if needed but one should note that even functions that can be called similarly, have an id parameter which is not present in ERC-3643 so the effort in the end might not be fully justified. Open to discussions.
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.
I see EIP-7943 being a subset and a primitive of ERC-3643 and not the other way around. I view EIP-7943 as a foundational interface that could serve as a building block. It’s intentionally minimal with a single interface and essential functions. This approach allows for broader participation in RWA standardization beyond projects with specific architectural requirements.
Let’s avoid fragmenting the ecosystem with several standards serving the same purpose.
Given that ERC-3643 is finalized and cannot be modified, and considering its comprehensive architecture, it’s challenging to integrate uRWA as a subset. The finalized status, while providing stability, does limit the ability to evolve the standard for emerging use cases and architectural approaches. Using the argument that ERC-3643 is finalized can’t justify the lack of flexibility and compatibility and is not justification to label 7943 as fragmenting.
We invite anyone passionate about RWA tokenization to join forces , not create parallel forks.
While ERC-7943 is fundamentally different for being considered a fork (again, 7943 seems more like a primitive of 3643 in this sense), we also invite anyone to share their needs, concerns and experiences to build something that is consensual and broadly applicable.
In short:
-
RWAs are diverse and that’s why a standard for those should be flexible and maximally compatible. RWAs are also complex and require to respect regulations that continuously change, for this a standard for them must not be rigid and must be general and future proof. This is the main set of motivations that derived into EIP-7943.
-
I don’t believe there’s a way to work around ERC-3643 and I believe a different standard is needed. Naming of 7943 functions can be adapted if needed.
-
Wide builders adoption must be achieved before finalizing the ERC so that the highest chances of adoption are obtained through the whole ecosystem. In this sense I am happy to collaborate into something new that builds on the motivations (flexibility, maximally compatible, general and future proof) behind this standard attempt.