0x33b12e7933b1…33b12e76

ConfirmedTokenization & RWA592 vB31 sat/vB3 min decode

Ethereum Draft Adds Compliance Hooks to Confidential RWA Tokens

Ethereum developer Aryeh Greenberg proposed PR #2034 to extend ERC-7984 with eligibility checks, freezing and forced transfers for confidential real-world asset tokens, challenging notary-based alternatives.

Outputs

  1. PR #2034 opened Thursday evening ET by developer Aryeh Greenberg and remains an unmerged draft

  2. The interface extends ERC-7984, which represents balances and amounts as confidential pointers

  3. ERC-7943 already defines eligibility, freezing and forced transfers for transparent RWA tokens

  4. Visa and Brale announced a Canton stablecoin proof of concept on June 4 using the SBC token

  5. Canton operates as a public Layer 1 with partition-based privacy, unlike Ethereum's token-level proposal

Ethereum developer Aryeh Greenberg opened pull request #2034 to the Ethereum ERC repository Thursday evening, proposing a token interface that would add eligibility checks, freezing and forced transfers to confidential tokens representing real-world assets.

The submission extends ERC-7984, an unmerged draft standard that represents balances and transfer amounts as confidential pointers rather than publicly readable numbers. The proposal targets a structural gap in tokenized RWAs: how to enforce issuer compliance rules when the underlying transfer values must stay private.

The finalized ERC-7943 RWA interface already defines eligibility, freezing and forced transfers for standard tokens, but assumes balances and amounts are publicly readable. Greenberg's draft adapts that enforcement model for confidential implementations.

What does the interface actually require?

Applications can verify publicly whether an address is eligible to send or receive the token, while routing the transfer amount and the spendable balance through confidential results. Spendable balances must net out restrictions including freezes, lockups and vesting schedules.

The draft leaves the privacy stack open. It does not mandate a specific cryptographic scheme and does not designate which parties may resolve the confidential pointers. That design pushes the choice of zero-knowledge proof system, trusted execution environment or another mechanism to each implementer, and places the operational security burden on the issuer rather than the standard.

Where does enforcement authority sit?

The interface preserves issuer control through a forced-transfer function. An authorized party can move tokens without the holder's consent, a capability typically required for regulatory recovery actions. That function bypasses the normal confidential transfer check but must reject ineligible recipients, preventing issuers from moving tokens to blacklisted addresses.

The draft deliberately omits separate interfaces for minting, burning, halting and freezing, leaving those mechanisms to the issuer's deployment logic. Developers integrating the standard are advised to transfer zero tokens rather than revert a failed confidential transfer, because a public revert can leak balance information to outside observers.

How does it differ from the notary-based alternative?

A parallel proposal, pull request #1850 describing ERC-8322, takes a different route. Its Notary-Backed Confidential Token draft keeps ownership and amounts offchain and relies on a designated notary to validate private transactions. The public contract records commitments and blocks reused inputs.

The notary draft makes its trust trade-off explicit: a compromised notary could submit invalid transactions or inflate private supply. Greenberg's design distributes enforcement across the token contract itself rather than concentrating it in a single validator, though it inherits whatever trust assumptions the underlying confidential-pointer system requires.

Why are institutions testing alternative rails?

The same confidentiality requirement is driving institutional interest in permissioned networks. On June 4, Visa and stablecoin issuer Brale announced a proof of concept using Brale's SBC stablecoin on Canton, a public Layer 1 blockchain whose privacy model distributes only the relevant parts of a transaction to entitled participants.

Visa's head of crypto, Cuy Sheffield, said the work targets settlement requiring "both programmability and privacy controls." Canton's Daml smart-contract language defines which participants can act on and view each piece of data, a model the Ethereum draft does not replicate. The Ethereum proposal instead standardizes the token interface and leaves the underlying privacy system to each implementer.

Both ERC-7984 and PR #2034 remain unmerged drafts. Any deployment would require implementers to commit to a specific privacy stack and a designated resolver role before the interface can function in production, and any standardization timeline depends on Ethereum ERC editor review and community feedback on the open pull requests.

via raw.githubusercontent.com (Original)

More from Daniel Okafor

Daniel Okafor

Show full bio

Correspondent covering industry trends and analytics at Mempool Brief.

435 articles