Add Zama confidential wrappers

[melanciani]

No description provided.

[manuelwedler]

Hey there :)
We've been recently adapting the testing CI to run tests against the TypeScript and Rust libraries at the same time. For this, we needed to change the test file format. Could you please do the following:

• Rebase this PR on latest master
• Have a look at the updated README for documentation on the new test format
• Add test files in the v2 format
• Remove the test files in the old format

Thank you! We will have a look at the PR afterwards.

[github-actions]

Clear Signing Tests

Tested b908b2c · started 2026-08-28 21:08 UTC · finished 2026-08-28 21:09 UTC

Entity	Descriptor	Case	@ethereum-sourcify/clear-signing@0.2.2	llbartekll/clear-signing@0.1.0
zama	calldata-ACL	Delegate user-decryption for a specific contract until a future timestamp	✅	✅
zama	calldata-ACL	Delegate user-decryption across all contracts (wildcard) until a future timestamp	✅	✅
zama	calldata-ACL	Revoke user-decryption delegation for a specific contract	✅	✅
zama	calldata-ACL	Revoke user-decryption delegation across all contracts (wildcard)	✅	✅
zama	calldata-ACL	Revoke user-decryption delegation on Sepolia (testnet deployment, chainId 11155111)	✅	✅
zama	calldata-ACL	Delegate user-decryption on Sepolia (testnet deployment, chainId 11155111)	✅	✅
zama	calldata-ConfidentialWrapper	Shield 1000000 underlying tokens to a receiver	✅	✅
zama	calldata-ConfidentialWrapper	Shield 1 WETH on cWETH, whose underlying has 18 decimals	✅	✅
zama	calldata-ConfidentialWrapper	Request to unshield using a known encrypted amount handle	✅	✅
zama	calldata-ConfidentialWrapper	Request to unshield with an external encrypted amount and input proof	✅	✅
zama	calldata-ConfidentialWrapper	Finalize unshield with cleartext amount and decryption proof	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer with a known encrypted amount handle	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer with an external encrypted amount and input proof	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer from a holder using a known encrypted amount handle	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer from a holder with an external encrypted amount and input proof	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer with callback using a known encrypted amount handle	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer with callback using an external encrypted amount, input proof and callback data	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer from a holder with callback using a known encrypted amount handle	✅	✅
zama	calldata-ConfidentialWrapper	Confidential transfer from a holder with callback using an external encrypted amount, input proof and callback data	✅	✅
zama	calldata-ConfidentialWrapper	Authorize an operator until a future timestamp	✅	✅
zama	calldata-ConfidentialWrapper	Revoke an operator by setting the authorization to expire at the epoch	✅	✅
zama	calldata-ConfidentialWrapper	Request public disclosure of an encrypted amount	✅	✅
zama	calldata-ConfidentialWrapper	Disclose an encrypted amount publicly with cleartext value and decryption proof	✅	✅
zama	calldata-ConfidentialWrapper	Shield on Sepolia (testnet deployment, chainId 11155111)	✅	✅
zama	eip712-DelegatedUserDecryptRequestVerificationV1	Authorize delegated user decryption for a single contract on mainnet	✅	✅
zama	eip712-UserDecryptRequestVerificationV1	Authorize user decryption for a single contract on mainnet	✅	✅
zama	eip712-UserDecryptRequestVerificationV1	Authorize user decryption on Sepolia (testnet, chainId 11155111)	✅	✅
zama	eip712-UserDecryptRequestVerificationV2	Authorize unified (v2) user decryption for a single contract on mainnet	✅	✅
zama	eip712-UserDecryptRequestVerificationV2	Authorize unified (v2) user decryption on Sepolia (testnet, chainId 11155111)	✅	✅

✅ pass · ❌ fail · ⚠️ error · ⏭️ skipped · — not run

📋 View test details

[manuelwedler]

Note that tests will likely fail because at least the TypeScript library does not support encryption yet (I assume the Rust library too).

[melanciani]

@manuelwedler I've updated the test for the v2 version, ran them locally and confirm there is some missing logic in the ts library (and indeed probably rust), do you confirm they come from https://github.com/sourcifyeth/clear-signing/ and https://github.com/llbartekll/clear-signing ? am i expected to open PRs there ?

[manuelwedler]

@melanciani I don't think you are expected to open PRs. We should get the libraries to a state where the full 7730 spec is implemented. So I just created a draft PR on the sourcify library: sourcifyeth/clear-signing#56. You can take a look at it if the implementation makes sense like this (I didn't verify what is written in DECRYPTION.md myself yet though).

I'm undecided if we need to get this implemented on both libraries before this can be merged, as it's a very specific feature. Nevertheless, you can create a PR on llbartekll/clear-signing yourself if you feel like it.

[melanciani]

thanks a lot @manuelwedler , I've reviewed your PR (just made a minor comment) + opened an equivalent of your PR in the rust lib: llbartekll/clear-signing#10 !

imo having support for the encryption scheme is a great benefit to the libs so would be great to try to integrate them both !

[melanciani]

hey @manuelwedler, the PR has been updated and is ready for review. I can see that the CI is green for both ts and rust libs: #2595 (comment) !

[kuzdogan]

Thanks for this. I checked the deployments and have two questions before we go further.

1. Proxies. All 20 calldata addresses (the 2 ACL and the 18 ConfidentialWrapper deployments) are ERC1967Proxy contracts. On mainnet every wrapper proxy points at the same implementation, 0x2ABad2203Eba104b52cf040cCcFA100Df15687F8, and on Sepolia at 0xAe37b998d453E1FaBE85DD46cf04295ca4A3af04; both implementations are verified on Sourcify and byte-identical apart from metadata. I don't recall us discussing this case specifically, and how we handle proxies is still unclear to me in general. The spec says descriptors should be bound to the implementation, not the proxy. Since all proxies here share one implementation, would it make sense to bind the wrapper descriptor to the implementation address instead of listing the 18 proxies? Happy to hear how you see it.

2. EIP-712 verifying contracts. The three EIP-712 descriptors declare 0x0f6024a97684f7d90ddb0fAAD79cB15F2C888D24 on mainnet and 0x5D8BD78e2ea6bbE41f26dFe9fdaEAa349e077478 on Sepolia. Neither address has code on those chains. Our understanding, from the relayer SDK: the Decryption contract lives on Zama's gateway chain, and the SDK builds the EIP-712 domain with the host chainId (1 / 11155111) together with the gateway contract address, so wallets look up exactly the pair the descriptors declare, even though nothing is deployed there on the host chain. Is that accurate? We are writing it down here for future reference, since none of our checks (Sourcify, Etherscan, bytecode) can verify these two entries.

_{Posted with Claude Code}

[melanciani]

hey again @kuzdogan , great questions indeed:

1. Could you clarify a bit where you see that specs talk about binding to the implementation ? In the EIP 7730 specs, the upgrade paragraph says that the registry should consider the proxy address :

Upgradeable proxy contracts (such as Transparent Proxies or UUPS proxies as defined in [ERC-1822](https://eips.ethereum.org/EIPS/eip-1822)) use a fixed proxy address that delegates calls to a replaceable implementation contract. For these contracts, the ERC-7730 file SHOULD be bound to the proxy address, since this is the stable address users interact with.

imo this makes more sense. Putting the implementation address means anytime we upgrade the proxies, the registry will need to change. Also, the user directly calls/sees the proxy address when signing, not the implementation one, so I'm curious how that would look. But maybe I'm missing something here

2. Yes indeed, I should have made this point more clear. The EIP712 are signed on Ethereum but are actually propagated and verified on the gateway chain (chainIds: mainnet: 261131; testnet: 10901). For this to work, we've updated the way these signatures are verified onchain (https://github.com/zama-ai/fhevm/blob/main/gateway-contracts/contracts/Decryption.sol#L1135). For the record, initially, we were actually making users sign for the gateway chain to avoid this. However, since wallets were still connected to Ethereum when signing the EIP712, they were displaying a big (and very reasonable) warning message as the chainId differed, and we preferred to avoid that ! With that being said: I indeed don't see any proper solution around this convoluted mechanism with the current schema. A suggestion would be to update the spec as such, although I think the deployments semantic now becomes misleading + it is very specific to edge cases like us: Update ERC-7730: update EIP712 deployment chainId ERCs#1976

[kuzdogan]

Thanks for answering those, now it's clearer.

1. I realized I was only referring to the 3rd type of proxies e.g. Safe Proxies where there's a reference implementation and all instances are proxy contracts pointing to the reference. For those it's infeasible to add every single proxy, and here the descriptors need to be bound to the implementation.

For upgradable proxies, the spec indeed tells to point to the proxy, as you point out. I'd still argue this is a bit dangerous since the proxy implementation can move (maliciously or not) and the users might think they are still signing the same transactions. For that we either need to bind the spec to the implementation and resolve proxies on the fly, or implement ethereum/ERCs#1738 such that we have guarantees over the delegated implementation address.

Even though it's not ideal as is, it seems fine as is and we can figure it out later.

This discussion also made the proxy issues clearer to me, thank you

2. All good, and just wanted to double check. In earnest the wording deployments is not accurate here. EIP712 messages are completely offchain and there is no deployment necessarily. It's just that usually the verifying contract is on that chainId and address, but as in your case, it can be totally different. It's rather the "domain" as named in EIP712

Anyway it's good as is. Thanks!