Standard for RWAs using ZAMA

Developer Program Builder Track
1

Not sure what the appropriate category is for questions about building on Zama.

Anyways, so where are we in terms of contract standards for RWAs? I’ve seen different kinds of approches and standards for this… What is the latest standard for this in your opinion?

I want to make a simple vault with monthly lock and revenue and wrapped token. Compliant and confidential.

I already have an IdentityRegistry.

About ERC-7984 as per ERC-7984 | OpenZeppelin Docs , I think CompliantERC20 ( CompliantERC20 | fhEVM Hub ) seems more compliant than ERC7984. Also what features ERC7984 adds that other standards don’t have? My problem with ERC7984Restricted , as illustrated in ERC7984Restricted.sol ( openzeppelin-confidential-contracts/contracts/token/ERC7984/extensions/ERC7984Restricted.sol at master · OpenZeppelin/openzeppelin-confidential-contracts · GitHub ) is that it isn’t natively compatible with IdentityRegistry and it exposes KYC result ‘UserRestricted’, which is non compliant (CompliantERC20 prevents this).

Do we know of a good middle ground? Something like ERC7984Rwa but with the transfer logic of CompliantERC20 (using IdentityRegistry)?

2 Likes
2

Hi there, Ankur here from the Product team at Zama. I wasn’t aware of the CompliantERC20 example from the fhEVM Hub docsite, which seems to have been created by one of the more prolific members of the Zama developer community.

There’s quite a few different RWA token specifications out there, one of the big ones being ERC-3643. We’ve been working with OpenZeppelin on a confidential version of that currently named ERC7984Rwa, which is still in the draft stage. It doesn’t (yet) have the identity, compliance, and role-based access control features fully hooked in yet. However, we expect to have it ready in the in the coming months. I expect it to ultimately have it own ERC; the deviation I’d expect is that it’s not an exact 1:1 copy of “ERC-3643 with confidential fields”.

If you want to build something before that RWA version is released, inheriting from ERC-7984 is probably the right direction to go in, as it will likely be a similar space that whatever ERC7984Rwa ends up in.

1 Like
3

Thank you for the answer Ankur!

So where can I see the transfer function for ERC7984Rwa atm? I’m seeing canTransact but I’m not seeing the tsf implementation.

Looking forward to hearing more about the ERC7984Rwa!

FYI for me the two requirements are:

  • Reusable KYC using IdentityRegistry
  • no error on failed KYC for compliance
4

I’m also building a compliance-sensitive payments primitive on fhEVM (ConfidentialPayroll: github/X-PACT/confidential-payroll) so this question resonates.

My current mental model is:

- ERC-7984 gives you the confidential “ERC20-like” baseline for encrypted balances/allowances, but it doesn’t prescribe a strong compliance policy surface.

- CompliantERC20 looks closer to a production compliance layer because it can gate transfers via an IdentityRegistry without exposing a binary “restricted” signal on-chain.

Two questions to help us converge on a “middle ground” standard:

  1. What is the recommended pattern to integrate IdentityRegistry checks into an ERC-7984-style confidential token WITHOUT leaking KYC outcomes?

    • Ideally: revert reasons / on-chain events should not reveal whether the failure is due to KYC vs other constraints.

    • Is “constant-time / constant-signal” failure a design goal for the team?

  2. Would Zama/OZ consider a reference extension like `ERC7984Compliant` that:

    • delegates eligibility to IdentityRegistry (or a policy contract),

    • uses uniform failure signaling (same revert path) to avoid leaking restriction status,

    • supports “transfer restrictions” for RWA vault flows (monthly lock / revenue distribution) without revealing which rule triggered?

In my case (payroll), I need:

- periodic distributions,

- receiver eligibility,

- minimal information leakage about compliance decisions.

Happy to share concrete patterns/tests frAlso curious if the team recommends keeping the compliance decision purely off-chain via gateway attestations vs on-chain registry checks for RWA-grade confidentiality.om my repo if helpful.

1 Like
5

I’m also building a compliance-sensitive payments primitive on fhEVM (ConfidentialPayroll: github/X-PACT/confidential-payroll), so this thread resonates.

Context / Mental model

ERC-7984 gives a solid confidential “ERC20-like” baseline (encrypted balances/allowances), but doesn’t define a strong compliance policy surface.

CompliantERC20 (OZ) looks closer to production compliance because it gates transfers via an IdentityRegistry, and aims to avoid exposing an obvious “restricted/not restricted” signal.

Goal

I’m trying to converge on a “middle-ground” standard/pattern for confidential tokens with compliance, where:

transfer eligibility is enforced,

but KYC outcomes and rule triggers are not leaked via events/revert reasons.

Questions

  1. Recommended integration pattern (IdentityRegistry + ERC-7984)

What is the recommended way to integrate IdentityRegistry/policy checks into an ERC-7984-style confidential token without leaking KYC outcomes?

Specifically, how do we avoid leaking:

whether the failure is due to KYC vs other constraints,

or which restriction rule triggered?

  1. Is constant-signal failure a design goal?

Is “constant-time / constant-signal” failure considered a design goal for Zama/OZ here? (e.g., same revert path, no distinguishing error strings/events)

  1. Reference extension idea: ERC7984Compliant

Would Zama/OZ consider a reference extension like ERC7984Compliant that:

delegates eligibility to IdentityRegistry (or a policy contract),

uses uniform failure signaling (same revert path) to reduce information leakage,

supports configurable “transfer restrictions” for RWA-style flows (monthly lock / revenue distribution) without revealing which rule triggered?

My concrete needs (Payroll)

periodic distributions,

receiver eligibility,

minimal leakage about compliance decisions.

Also curious: for RWA-grade confidentiality, does the team recommend:

keeping compliance decisions purely off-chain via gateway attestations, or

using on-chain registry checks (IdentityRegistry / policy contract)?

Happy to share concrete patterns/tests from my repo if helpful.