ERC-7943: Universal RWA Interface (uRWA)

ERCs
26

Previous value in Frozen event

Additionally, to better reflect your concern of indexing the correct unfrozen / frozen amounts during forceTransfers and burn, I’ve added a previousValue and newValue in the Frozen event, so that differences can be tracked. Now if a force transfer or a burn changes the freezing status, the Frozen event will emit both old and new value, so that changes in freezing status can be tracked.

I’m not sure emitting the previous value is necessary. If indexers want to keep track of the difference, they can check against their currently indexed value.

ERC20 tokens already behave by not emitting previous values in allowance nor balance changes. I’d argue the ERC-7943 should behave likewise.

Pausability

What makes me to hesitate about it [pausability] is:

  • Do all use cases need this ? If we can name a few that don’t neccessarily require it, I wouldn’t go with it.

I’d say the majority of permissioned tokens, of which securities and RWAs should be a subset of, use it.

Doing a minor research about it, I can find:

  • OZ already has an historical and battle tested, widely adopted, solution for pausable contracts and it’s easy to think about this as one of the multiple potential extensions of an ERC-7943 minimal token.

I agree that there’s no need to standardize it for ease-of-use of the feature, as OZ already has the de-facto standard for pausability.

I’m more concerned about having a clear criteria for what features are included in the baseline ERC. One can argue that token freezing is not necessarily required within the ERC, as it can be enforced through forceTransfer and vaults, but that it’s best to standardize it, and that pausability can be enforced through isTransferAllowed and extensions, but that it’s also best to standardize it.

I’d aim for what we envision will be the requirements for 90% of the tokens into the baseline ERC, and leave the rest to extensions.

That said, I don’t have enough insights on pausability requirements to take a clear stand on its inclusion. To me, although most tokens have it, it feels operative and not a core token functionality, similarly to upgradeability.

Unfreezing in forced transfers

Yes, cases in which the freezing authority has more power (higher priority) in the entity performing a forced transfer. Those might be two separate entities. You can give forceTransfer rights to one or more entities, and setFrozen rights to completely different entities. An example might be perpetual contracts where a continous funding mechanism might leverage the forceTransfer functionality. In this sense, the forceTransfer would be functional to a perpetual contract funding mechanism but might not have the freedom to move more than frozen assets, since those might be seized by goverments or higher level authorities than a smart contract logic for perpetual contracts. What do you thinkg about this ?

I’d argue forced transfers are not the correct action for that use-case. I believe it has the same implications than using native ERC20 approvals, as you still depend on the user not front-running you to collect the fees, and using an all-powerful permissioned function to execute core business logic doesn’t seem right.

Still, the EIP suggests both things now, a forceTransfer and a burning CAN skips the freezing validations, but they also CAN NOT skip those. The most important thing is that if those automatically unfreeze, the must emit a frozen event to reflect that, before the native transfer event.

I agree it’s most important that unfreezing emits the Frozen event before the native Transfer one, and that it should fix indexing concerns, if ForcedTransfer and Transfer can only occur with unfrozen balances.

I believe the decision is a trade-off between:

  1. Forcing unfreezing in forceTransfer and ensuring standard implementation.
  2. Allowing forceTransfer to revert on frozen balances and, therefore, a freezer role to be of higher status than a force transferer role.

I have a preference for option 1, as I don’t see any use-case for option 2 and consider forceTransfer a “last resort” permissioning function.

If we can come up with option 2 use-cases, it would make total sense to keep it unopinionated.

27

setFrozen probably doesn’t need to be part of the minimal interface. In a similar way as mint/burn, setFrozen is likely only ever going to be called by the contract’s owner/operator. The owner/operator obviously knows how to interact with their own contract, and so these functions don’t need to be part of the standard interface.

28

Thanks @tinom9 for cominb back. About this:

I’m not sure emitting the previous value is necessary. If indexers want to keep track of the difference, they can check against their currently indexed value. ERC20 tokens already behave by not emitting previous values in allowance nor balance changes. I’d argue the ERC-7943 should behave likewise.

The intention was to solve this point from our previous conversation:

While I agree that your suggestion of using ForcedTransfer to specify which tokens were frozen and which unfrozen, I think that the real place to reflect this is in the Frozen event and not in the ForcedTransfer (merely because of context, if we are specifying freezing/unfreezing amounts then Frozen event seems more accurate to me than ForcedTransfer.

Additionally, emitting previous and new value not only allows for a correct indexing, but can also give flexibility to offchain services to decide what to index (historical values, just the deltas, both, etc…) I agree that it’s not a common pattern for base tokens to do this in events but it’s also true that this token is uncommon and for this it needs a specific interface. Moreover, it is indeed somehow a standard practice when a value is overwritten with a new one.

Finally, doing this modification to the Frozen event would allow to avoid using MUST when talking about enforcing or not the freezing validations during a burn / forceTransfer, gaining in potential more use cases supported.

Connecting “more use cases supported” to our previous point:

If we can come up with option 2 use-cases, it would make total sense to keep it unopinionated.

and

I’d argue forced transfers are not the correct action for that use-case. I believe it has the same implications than using native ERC20 approvals, as you still depend on the user not front-running you to collect the fees, and using an all-powerful permissioned function to execute core business logic doesn’t seem right.

I believe what you say is particularly true if token holders are EOAs, but there’s an endless number of dynamics that can be unlocked when thinking about holders as smart contracts being part of one or more protocols. A part from the one I mentioned I can think of other ways of leveraging a forceTransfer being an operator and not an EOA owner:

  • escrowed payments between parties to settle payments (you don’t need to actually transfer tokens within the escrow contract when using a forceTransfer)
  • forced liquidations on lending protocols using external vaults as collateral
  • slashing on re-staking protocols

I feel like imposing a skip in freezing validation might automatically unable those dynamics and the one I didn’t thought about just yet. The main important thing that the standard says about those functions is that they should be restricted in access since they are powerful in their logic, but who can have access to them is not necessarily (even if likely in many cases) a last resort, high priviliged EOA actor or multisig.

Pausing

I’m more concerned about having a clear criteria for what features are included in the baseline ERC.

Totally agree and I believe this is key.

One can argue that token freezing is not necessarily required within the ERC, as it can be enforced through forceTransfer and vaults, but that it’s best to standardize it

It was my original thought indeed but there’s a fundamental difference between using forceTransfer + vaults compared to using setFrozen which is that assets never leave holder wallet with freezing. From a regulatory standpoint, my personal opinion is that freezing is a primitive which is different from a forced transfer as it is inherently different in terms of balance accounting and assets movements. I’ll try to summarize here the criteria I’ve used so far to include each function in the standard:

Generally speaking, I am confident to say that getters are the main reason to build an ERC and that trying to standardize setters is generally a thing only if you want to standardize also integrations/tooling/offchain services. So leaving aside the isUserAllowed / isTransferAllowed and getFrozen my reasoning for the setters are:

  • setFrozen: It makes sense to me to include it here because we are also standardizing getFrozen and including it in the context within the same ERC for completeness is sound to me. This should answer also your comment @SamWilsn , wdyt ?
  • forceTransfer: It makes sense to me to standardize it mainly because it includes ERC-20/ERC-721 and ERC-1155 at the same time and it’s a widespread feature with tons of different names and variations. I believe there’s a big benefit in standardizing it. Additionally, it can enable many potential and automated use cases that will benefir from a standardized function for it.

About the pausability, I don’t see any clear reason to include a setter for it since it’s already standardized elsewhere and this would leave us with potentially adding only the getter isPaused or paused which I believe overlaps a bit with the isTransferAllowed.

The same reasoning is what still convinces me to not include mint/burn since:

  • Trying to standardize mint/burn for ERC-20 / ERC-721 and ERC-1155 feels a too wide scope for this ERC. If one wants to do that, it should be outside of an ERC for “regulated” assets.
  • Still not convinced that all use cases need it so that it makes sense to enforce the presence of those functions. A token which is just a fixed pre-minted supply and it’s not meant to be burn doesn’t need them.

What do you think about above criteria @tinom9 / @SamWilsn ?

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!

4 Likes
30

Some quick thoughts:

  • A published ERC is not a standard. Just a document competing to become a standard by popular consensus
  • Standards are a result of shared coordination mechanisms; they don’t have a purpose nor intentions like avoiding fragmentation, they help coordinate, just that.
  • Overspecifying an ERC does fragment the industry, by leaving partial use cases non compliant (e.g. requiring ERC 173?)
  • Authors decide by themselves when to finalize their standards. After that the author’s will is gone and the document becomes the source of truth

Overall I agree with both 3643 and 7943 goals, but 3643 took its stand by finalizing itself and keeping “MUST” keywords all over the place rather than a lesser strict “SHOULD” or even suggestive “MAY”. In that case a modular alternative would’ve been possible.

In my opinion, the need 7943 is solving is for RWAs that may not need all the regulatory enforcement. There are jurisdictions in which promissory notes are decentralized by nature and 7943 accomodates those well. Promissory notes are anonymous peer-to-peer physical paper and some regulations allows operating them with any non-custodial wallet if they’re represented as an identifiable token, enabling small players to bring RWAs easily and in more innovative ways.

Another use case may include RWAs minted to wallets controlled by government-issued verifiable credential so the identity and expiration is embedded in the wallet and is revocable outside of the smart contract (e.g. through a central bank PKI)

I don’t think it’s about extending an existing restricting standard but rather coming up with a minimum viable subset. I don’t see how that’s possible with 3643 without missing specification requirements. So what would be the point of an ERC whose specification can’t be relied? Anyone calling an ERC-3643 can’t be sure if things work the same (aka. standardly)

2 Likes
31

Thanks for your input @ernestognw
But i believe there are some points to take in consideration :

While ERC-3643 admittedly spans a wide range of RWA use-cases, making certain features “overkill” for niche applications, it serves as a single, unifying standard already widely adopted by major institutions and Web3 providers.

  • Overkill vs. Unity
    ERC-3643 covers identity-linked issuance, role-based access control, compliance enforcement, forced transfers, freezing and more in one protocol. Yes, some of these are beyond what a simple promissory-note token needs, but using one well-supported, audited interface helps avoid a patchwork of half-baked forks.

  • Ownership (ERC-173) is fundamental
    Any permissioned RWA token requires an on-chain owner to satisfy issuer obligations (e.g., freezes, recoveries, governance). ERC-3643’s “MUST” support for ERC-173 ensures interoperability with wallets and admin tooling rather than arbitrary implementations.

  • EIP-1 calls for novel concepts
    Per EIP-1, a new ERC should introduce a genuinely new idea! Not merely rename existing functions or slice off subsets. If ERC-7943 doesn’t add unique primitives, it risks violating EIP-1’s guidance on focused proposals.

  • Minimal subsets must reuse names
    If the goal is a minimal interface, please adopt the same function signatures (isVerified vs. isUserAllowed, canTransfer vs. isTransferAllowed, etc.) to preserve compatibility and leverage the extensive tooling built for ERC-3643.

  • Fragmentation undermines interoperability
    Standards exist to foster interoperability and prevent duplicate, incompatible forks. Multiplying near-identical interfaces fractures developer effort and slows adoption.

  • Whitelist/freezes/mints are not new
    Everything in ERC-7943, from wallet whitelists (as in ERC-1400) to freeze/mint/pause semantics, is well-documented in earlier EIPs and OpenZeppelin modules. ERC-3643’s value lies in aggregating and standardizing these primitives in one coherent, audit-ready framework.

We’re actively maintaining and extending ERC-3643 with industry partners and the ERC3643 Association (120+ Members strong). We invite anyone passionate about RWA tokenization to join forces, not create parallel forks.

32

Proposal: Add tokenScope () to uRWA Interface for Compliance Proportionality

Hello everyone,

I’d like to propose the introduction of a minimal but meaningful addition to the uRWA standard that could enhance its legal clarity and institutional usability without sacrificing its modular and lightweight philosophy.

:dart: What’s the proposal?

Add an optional enum + getter function to the interface:

enum Scope { Public, Private, Custom }

function tokenScope() external view returns (Scope);

This would allow implementers to express—on-chain and from the start—whether the tokenized RWA is intended for:

  • Public distribution: e.g., listed on public exchanges or accessible broadly under general KYC/AML.
  • Private offering: e.g., restricted to whitelisted or qualified investors.
  • Custom logic: complex regulatory flows (jurisdiction-based, hybrid convertible instruments, etc.).

:scroll: Legal Justification

Regulations like MiCA (EU) or Reg D / Reg S (US) make sharp distinctions between public and private offerings.

Today, there’s no universal on-chain signal that clarifies this distinction. As a result:

  • Some RWA tokens are listed in contexts where they shouldn’t.
  • Compliance tools and custodians lack clear inputs to automate their logic.

By adding tokenScope(), integrators like exchanges, compliance oracles, or investor portals could:

  • Automatically apply proportional compliance measures.
  • Prevent accidental misuse or overexposure of private tokens.

This enables “compliance by design”, encoded at the protocol level.

:hammer_and_wrench: Technical Alignment

This proposal is in line with uRWA’s modularity goals:

  • It does not impose logic into isUserAllowed() or isTransferAllowed().
  • It merely signals intended operating scope of the asset.

:white_check_mark: Practical Use Cases

  • Listing gatekeepers could read tokenScope() before allowing a token to go live.
  • Compliance modules could restrict or automate KYC flows accordingly.
  • Auditors and regulators could more easily verify issuance intentions.

Example:

if (tokenScope() == Scope.Private) {
  revert("This token is not eligible for public listing.");
}

:brain: Strategic Benefits

  • Empowers issuers to clearly declare intent on public vs private usage.
  • Helps integrators, marketplaces, and wallets prevent regulatory friction.
  • Opens the door to automated modular governance across compliant RWA stacks.

Would love to hear feedback on this.

Happy to prepare a pull request to the EIP draft or interface repo if there’s interest.

Best,

Pablo

1 Like
33

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.

5 Likes
34

Hi @Joachim-Lebrun

since other pain-points were already said I will mention the identity part.

Which pain-points in existing RWA implementations motivated a completely separate interface rather than an extension or variant of ERC-3643?

ONCHAINID.

Glad @ernestognw brought up all the “MUST”. Based on the EIP-3643 ONCHAINID is in the MUST category and later the specification was toned down to be more vague but the underlying interfaces and MUST to integrate stayed.

Screenshot 2025-06-19 at 13.45.30

This can create a lot of issues in terms of adoption since not everyone wants to use ONCHAINID and be tied into one ecosystem. Thats whats so welcoming about @xaler proposal, its lightweight and issuers can decide which verification solution to choose and not be forced to use a predetermined one.

EIP-3643 repo source

1 Like
35

Hi everyone,

Thanks for the detailed discussion. At this point it seems we have fundamental, irreconcilable differences, so let’s agree to disagree and close this thread:

  • Collaboration vs. Competition
    It’s clear you’re intent on building ERC-7943 in parallel rather than contributing to ERC-3643. We respect that choice but will continue advancing the proven, audit-ready ERC-3643 workstream.

  • Open Source Reality
    Contrary to the suggestion that ERC-3643 is closed or tied to a single company, the full specification and reference implementations are openly available under GPLv3 here: https://github.com/ERC-3643/ERC-3643.
    The same goes for ONCHAINID, and we are actually working on defining a minimal interface standard for ONCHAINID as well and propose it as an ERC to make sure any smart account can add the required interfaces to hold verifiable claims.

  • Institutional Endorsement
    Tokeny, the original author of ERC-3643, was recently acquired by APEX precisely because ERC-3643 has become the go-to standard for RWA tokenization. Dozens of industry players and regulated institutions are already building on it.

  • Whitelist Isn’t Innovation
    A simple wallet whitelist, freezing, minting or pausing aren’t new. They date back at least eight years (ERC-1400, OpenZeppelin modules, etc.). That’s not innovation, it’s actually a step backward from true identity-centric compliance.

  • Time & Focus
    We all have limited time. We’ll dedicate ours to strengthening ERC-3643’s ecosystem rather than chasing parallel drafts that mirror existing functionality.

In short:
We’ll continue to champion and extend ERC-3643 with the ERC3643 Association, APEX, Tokeny and our institutional partners. If ERC-7943’s authors ever wish to bring truly novel compliance primitives or identity models into a unified RWA standard, you know where to find us :slightly_smiling_face:

Thanks for the exchange, and all the best on your own RWA journey!

1 Like
37

Hey @pablock thanks for this, it seems interesting indeed. I want to understand more.

Is a type expected to change during the life course of a token ? Would be great to expand on corner cases.

Is there any expected type which are more explicit than custom ?

38

Thanks @Joachim-Lebrun !

proven, audit-ready ERC-3643 workstream

What’s proven and audited I believe is the standard implementation, Tokeny one.

Whitelist Isn’t Innovation

I agree with this. Indeed 7943 gives freedom of implementation, not enforcing it.

Contrary to the suggestion that ERC-3643 is closed or tied to a single company

Some stuff that might suggest the contrary:

  • No known implementations outside Tokeny one. Please correct me if wrong.
  • Tokeny being mentioned in the finalized draft of the EIP several times.

Tokeny is still brought in even in this thread:

Tokeny, the original author of ERC-3643, was recently acquired by APEX

We’ll continue to champion and extend ERC-3643 with the ERC3643 Association, APEX, Tokeny and our institutional partners

I appreciate a lot the attempt in comparing the functionalities here, but I believe we are focusing on two different things, with EIP 7943 being focused on a minimal flexible and maximally compatible standard to enable wide builders adoption and dozens of different implementations and tokens aligned within the same standard.

Good luck with everything !

2 Likes
39

At this point it seems we have fundamental, irreconcilable differences, so let’s agree to disagree and close this thread

I hope we have not reached this point yet! We all want shared standards for RWAs that all RWA builders are happy to use.

Does the ERC-3643 community recognize that this standard may be over-specified in some ways? And that therefore it may not be a perfect fit for all RWA use cases?

If yes, perhaps the 3643 community can join this discussion so that we can build a more lightweight standard together that suits everybody, and 3643 can remain as the more specialized one. To achieve this we should definitely, for example, make sure that the same functionality in both standards is named the same.

If we were starting from scratch, we might ideally organize things with 7943 as the one being extended by 3643. We can practically make that happen now.

4 Likes
40

Just to be clear. It’s just that we can’t do this. I would be happy to do so if the standard allow it :frowning:

3 Likes
41

(post deleted by author)

42

@Joachim-Lebrun and @xaler

First of all, thank you for raising important points regarding EIP-7943 and its relationship with ERC-3643. I am going to share my legal-know on the matter of regulatory requirements and technical ones.

The argument for embedding identity-linked compliance directly into the token standard, as implied by ERC-3643, is both legally and technically flawed. EIP-7943 is not designed to replicate ERC-3643’s internal logic. Instead, it aims to establish a neutral, extensible interface layer that accurately reflects the true enforcement perimeter in global financial regulation. This approach makes EIP-7943 necessary, legally sufficient, and ultimately superior as the universal interface standard for tokenized real-world assets.

Here’s why:

  1. Legal Frameworks Mandate Enforceability, Not Specific Architecture

Contrary to certain assumptions, no major jurisdiction (including the US, EU, UK, and Singapore) dictates a specific token architecture for compliance. Legal obligations are placed on regulated actors, not smart contracts. These obligations require specific outcomes, such as eligibility gating or transfer restrictions, but they do not prescribe the technological implementation.

  • United States – SEC Regulation D (Rule 506): United States – SEC Regulation D (Rule 506): While requiring “reasonable steps” to verify investor status and imposing resale restrictions, SEC guidance explicitly permits off-chain validation or credentialed attestations. This includes the use of third-party KYC providers, legal opinions, or cryptographic proofs (e.g. zk-credentials) that demonstrate compliance without requiring on-chain identity mapping. EIP-7943’s isUserAllowed(address) and isTransferAllowed(from, to, …) functions enable this kind of flexible enforcement by allowing implementers to point to attestation registries, oracles, or privacy-preserving verification systems. ERC-3643’s reliance on a centralized identity registry is incompatible with these approaches. Registry-based systems require address mappings approved by a validator authority, which creates friction for use cases involving decentralized investor credentials, self-custody, or key rotation. In such systems, every change in wallet or identity representation requires reapproval through the registry, breaking compatibility with modular KYC frameworks, session-based wallets, or user-held verifiable credentials. From a regulatory perspective, what matters is that the issuer can demonstrate compliance — not that it is enforced through a fixed registry — which is why open, modular compliance interfaces like EIP-7943 are better aligned with the evolving standards around attestations and digital identity under Reg D.

  • European Union – MiFID II, Prospectus Regulation, PRIIPs: EU financial regulation separates the role of the issuer (the entity creating and structuring the financial instrument) from the role of the distributor (the firm offering or selling the instrument to investors). Under MiFID II and the Prospectus Regulation, compliance obligations such as suitability assessment, product governance, and retail targeting are the legal responsibility of distributors, not issuers. PRIIPs, in particular, places disclosure obligations (e.g. Key Information Documents) on the distributor or manufacturer targeting retail clients. EIP-7943 aligns with this structure. It allows external platforms to integrate their own eligibility logic, disclosures, and distribution controls using modular metadata and permissioning hooks. This is particularly important for tokenized funds or syndicated offerings, where multiple regulated distributors manage their own onboarding flows and investor obligations. ERC-3643’s architecture centralizes control through issuer-appointed agents managing identity verification and compliance validation. While this allows for delegation through the agent system, it requires all compliance logic to flow through the issuer’s contracted infrastructure. Additionally, the issuer retains power on removing agents anytime. This may create implementation challenges for complex distribution frameworks where multiple independent entities need autonomous compliance authority, such as certain MiFID distribution arrangements where distributors must maintain direct regulatory responsibility for their client relationships

  • United Kingdom – FSMA, AML 2017, GDPR: The FCA explicitly supports technology neutrality. Compliance hinges on outcomes and auditability, not architectural constraints. EIP-7943 can support Travel Rule compliance, blacklists, and investor scoring through external engines that can be operated by issuers, custodians, or service providers. ERC-3643’s approach, which embeds identity mapping and validation directly into the token via a centralized IdentityRegistry, may create legal exposure under UK GDPR. This architecture introduces potential complexities with principles such as data minimization, right to erasure, and purpose limitation — especially in scenarios where the issuer controls both the registry and enforcement logic. In such cases, the contract itself may become a data controller, increasing operational risk and reducing flexibility for compliance delegation.

  • Singapore – SFA, MAS Guidelines, Project Guardian:
    The Monetary Authority of Singapore (MAS), through its Securities and Futures Act (SFA) and related guidelines, supports modular, externally enforceable compliance frameworks. Platforms regulated under the SFA are responsible for enforcing licensing conditions, investor restrictions, and AML/CFT obligations — but MAS does not prescribe specific on-chain architectures for doing so. Instead, it evaluates whether outcomes can be audited, controlled, and adjusted based on regulatory scope. In line with this, Project Guardian, MAS’s flagship initiative for institutional DeFi, explicitly promotes interoperability between public blockchain infrastructure and off-chain compliance engines operated by licensed intermediaries. Permissioning and KYC logic are expected to be flexibly integrated, not hardcoded into token contracts. EIP-7943 supports this design by exposing standardized permissioning hooks (isTransferAllowed) while leaving the enforcement layer modular. This allows MAS-regulated entities to maintain control over compliance logic while ensuring transparency and standardization. By contrast, ERC-3643’s issuer-controlled registry architecture requires that all investor validation and transfer permissions flow through a centralized validator list, which is typically managed by the issuer or its delegate. This restricts the ability of regulated platforms to independently implement or adjust compliance logic based on their own licensing obligations, counterparty types, or business models — limiting the flexibility promoted under the Project Guardian framework.

  1. Compliance Resides in the Process, Not Solely in the Token

Compliance is achieved through a multi-faceted approach involving:

  • Onboarding procedures (KYC/AML/CDD)
  • Off-chain documentation and attestations
  • Role-based access and distributor obligations
  • Ongoing monitoring, audit, and legal reporting

EIP-7943 reflects this reality by providing minimal, modular hooks for these processes, without prescribing a specific legal theory or identity model. ERC-3643, however, conflates compliance implementation with interface design, embedding registry and identity assumptions into its base architecture. This limits its compatibility with evolving landscapes such as self-sovereign identity, decentralized attestations, smart legal wrappers, and multi-actor custodial workflows.

  1. ERC-3643 is a Product Architecture, Not a Universal Standard

A universal compliance standard should be interface-level, modular, and vendor-neutral. ERC‑3643 reflects the implementation logic of a vertically integrated product and assumes:

  • All compliance flows through issuer-controlled identity registries
  • Identity is bound to wallet addresses through a centralized registry

These design choices hardcode governance and enforcement authority into the token layer, limiting flexibility for implementers. As a result, ERC‑3643 presents several structural limitations:

  • It cannot accommodate jurisdictions that require decentralized identity or data minimization (e.g. GDPR, UK GDPR, PDPA, Reg D)
  • Its complexity harden compatibility with wallet abstraction models such as MPC wallets, session keys, or smart contract-based custody

It restricts compliance delegation in multi-party architectures, including custodial enforcement, multi-distributor ecosystems, and DeFi–TradFi bridging.

3 Likes
43

Previous value in Frozen event

@xaler

To close this thread, to me it’s redundant to emit the previous value, as an indexer tracking frozen balances would most probably be also tracking allowances or balances, which don’t offer this feature.

That said, it’s a nitpick, I don’t think there’s much impact in going either way.

Unfreezing in forced transfers

@xaler

I believe your examples are better off using native ERC20 approvals or token vaults, due to simplicity and security concerns.

Escrowed payments, if kept as balances, should disallow transfers or they’d behave as ERC20 approvals. Therefore, it’s a choice between forced transfers with frozen balances or custom compliance rules, and a token vault. Allowing application-access to multiple higher-level functions seems to me wrong in principle.

Forced liquidations or slashing should also use a mix of permissioning functions or token vaults.

I see your point in making it as flexible as possible. I believe the underlying disagreement lies in that, to me, the token standard should incentivize applications to be built on top of the non-permissioned features, and leave permissioned functions to governing bodies, possibly EOAs, multisigs or governance contracts.

Coming back to the issue, enforcing or not the unfreezing of tokens in forced transfers is also a nitpick. My point stands, but I’d be ok either way. More community feedback on the underlying topic (permissioned features open or closed) would be much appreciated.

Pausability, setters & inclusion criteria

@xaler, @SamWilsn

Standardizing getters and user-facing functions is obviously the main point of the ERC, as most of the usage will come from end-users and their interactions with wallets.

I see the point in standardizing setters if there’s no evidence for diverging behaviours or use-cases: the benefit for having integrations and tooling adapt to a common behaviour and interface outweighs the noise from a heavier ERC.

I can sense some evidence of different wanted behaviours in minting and burning, although I don’t know if strong enough. I don’t see it in pausability.

To me, the strongest reason for not including the full pausing feature is overlapping with isTransferAllowed. Still, my point stands.

I would love to hear more community feedback on the topic.

Partial compatibility with ERC-3643

@Joachim-Lebrun

There’s obviously benefit in partially inheriting the ERC-3643 interface and expected behaviour where it’s possible: token freezing, forced transfers and transfer checks, for example; making it a subset of the previous and reutilizing available tooling.

We’ll probably encounter most friction in ERC-7943 being multi-token and breaking interfaces with the support for token IDs.

If there’s evidence of existing ERC-3643 tooling that would profit from joint interfaces for any of the features of the ERC-7943, a discussion is surely deserved!

Token scope

@pablock

It’s definitively a wanted feature to be able to identify a set of modular rules that apply to the token, as there can be common implementations, depending on jurisdiction or use-case (public or private offering).

I’d argue that, in favour of a leaner standard, these identification checks should be performed with the already included ERC-165 and not an additional getter.

1 Like
44

Hey @tinom9 thanks for coming back !

Regarding your original point here

One thing that concerns me is that, if we don’t impose that forceTransfer unfreezes tokens (only if the transfer cannot be fully satisfied with the unfrozen balance), the tokens must be first unfrozen and then forcefully transferred, adding the requirement to execute those calls in batch to avoid being front-run on the forceful transfer by the user.
I see the benefit of imposing the forceTransfer implementation in that we don’t end up with a method that behaves differently in different tokens with a core functionality such as token freezing. Either we need to extend the ForcedTransfer event to specify which tokens were frozen and which unfrozen, or we need to impose the implementation (MUST), if we want integrators to accurately index frozen and baseline balances.

I believed that by “accurately index frozen and baseline balances” you meant a way to know how many assets were frozen within the forceTransfer so that’s why I expanded on the even to reflect old value, new value and potentially the delta. I agree with you that it sounds redundant but I thought it would better address your concern.

I’ll happily revert it back with just the new frozen value.

Unfreezing in forced transfers and burn

I completely understand your point of leaving permissioned functions out of the “flexibility” behaviour. The main blockers for me to agree with you is that I don’t feel too confident to say that those functions will never be in need to be used by less special parties or just automated contracts with several degrees of privileges.

I agree that more community feedback is welcomed here.

Pausability

I must admit I recognize the importance of having this feature in the standard as I believe the majority of use cases will need it just in case while others will explicitly require it.

The two reasons for me to not included are the slight overlap in isTransferAllowed (and we should also discuss whether pausability applies to forceTransfer and mint/burn) and the already standardized pattern for pausability in several libraries out there. I feel like re-defining it here is not ideal.

Thinking a bit more, while community feedback is also welcomed as you suggested (would be great to ear others opinion here), what if we include a new item in the security considerations section where we suggests to include pausability patterns when needed ? It would kinda make it in the EIP but not as part of the interface definition.

Partial compatibility with ERC-3643

I personally like the approach of @nickimenace but I struggle to see how to decouple id from functions to make it adaptable to ERC-3643, I’ll think a bit more on this.

Token scope

Great idea of leveraging ERC-165, we might explore a way to have different interfaceIds based on different scopes without overloading the interface indeed. If we explore this, to me would be a priority to not implies lot of instructions and guidelines in the EIP itself about it, I’d try to maximize minimalism about this feature. But happy to hear more feedback about it.

This is looking great btw, I think we are already beyond the draft status but let’s keep iterating and bringing more feedback in :muscle:

45

Previous value in Frozen event

Thanks for bringing up the original comment, I see now what may have caused the misunderstanding. I could’ve been more explicit about the point.

One thing that concerns me is that, if we don’t impose that forceTransfer unfreezes tokens (only if the transfer cannot be fully satisfied with the unfrozen balance), the tokens must be first unfrozen and then forcefully transferred, adding the requirement to execute those calls in batch to avoid being front-run on the forceful transfer by the user.

I see the benefit of imposing the forceTransfer implementation in that we don’t end up with a method that behaves differently in different tokens with a core functionality such as token freezing.

Unrelated, but it still holds, if forceTransfer reverts on frozen tokens, there are risks of frontrunning if the unfreezing isn’t batched with the transfer, and, as noted in the ERC draft, of re-entrancy in ERC721 or ERC1155.

Either we need to extend the ForcedTransfer event to specify which tokens were frozen and which unfrozen, or we need to impose the implementation (MUST), if we want integrators to accurately index frozen and baseline balances.

My point here was that there had to be an imposed implementation (MUST) on how the forceTransfer function behaves regarding frozen tokens, to accurately index whether transferred tokens were frozen or unfrozen.

  • 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.

As defined above in the ERC, it’s no longer a problem. If bypassing freezing validations (not enough unfrozen balance exists), tokens MUST unfreeze assets first.

I’d update to Frozen(address indexed user, uint256 indexed tokenId, uint256 amount).

Pausability

I don’t see much benefit in including a soft recommendation without interfaces in the security considerations section.

To me, in order of preference, it’s either:

  • Full interface definition (setter and getter).

  • Only-getter interface definition.

  • Leaving it out of the ERC, maybe adding it to the isTransferAllowed example rules.

Other threads

I’m aligned with your last comments on unfreezing in forced transfers, partial ERC-3643 compatibility, and token scope.

Let’s see if there’s more community feedback on them.

It’s looking great indeed, incredible job with the proposal so far!

1 Like