Conversation
WalkthroughThe documentation updates recommend ChangesZama FHEVM SDK integration
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Sequence Diagram(s)sequenceDiagram
participant Application
participant ZamaSDK
participant OpenZeppelinRelayer
participant Ethereum
participant ZamaRelayer
Application->>ZamaSDK: Encrypt counter increment inputs
ZamaSDK->>OpenZeppelinRelayer: Submit encrypted contract call
OpenZeppelinRelayer->>Ethereum: Send transaction
Ethereum-->>Application: Return receipt
Application->>ZamaSDK: Request counter decryption
ZamaSDK->>OpenZeppelinRelayer: Request EIP-712 signature
OpenZeppelinRelayer->>ZamaRelayer: Authorize user decryption
ZamaRelayer-->>Application: Return cleartext
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/guides/zama-fhevm-counter-guide.mdx`:
- Around line 257-268: Update the decryption example to use public decryption
first and call sdk.decryption.decryptValues only when pub.clearValues[handle] is
undefined; catch expected public-decryption failures to allow that fallback, but
rethrow unrelated errors. Preserve the existing public result when available and
the user-decryption result otherwise.
- Line 394: Update the “User decryption failed” troubleshooting bullet in the
Zama FHEVM counter guide to remove persistent storage as a required decryption
condition. Keep guidance about the relayer’s typed-data signing and configured
chain, and move any MemoryStorage/Redis advice to repeated-signing or cache-loss
troubleshooting only.
- Around line 131-132: The production signer recommendations in
docs/guides/zama-fhevm-counter-guide.mdx lines 131-132 must remove CDP and list
only hosted signer backends that support EIP-712 signing, while preserving the
guidance to prefer hosted signers over local. Update docs/zama-fhevm.mdx line
150 to explicitly require hosted signers to implement signTypedData.
- Line 57: Update the README link in the documentation list to use GitHub’s blob
route instead of the tree route, preserving the existing repository path and
README.md target.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fb80e95a-1499-4f1c-a466-dd6a6146f92a
📒 Files selected for processing (2)
docs/guides/zama-fhevm-counter-guide.mdxdocs/zama-fhevm.mdx
| - **Location**: [examples/relayers/zama](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/tree/main/examples/relayers/zama) | ||
| - **Documentation**: [README.md](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/tree/main/examples/relayers/zama/README.md) | ||
| - **Location**: [examples/relayers/zama/zama-sdk](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/tree/main/examples/relayers/zama/zama-sdk) | ||
| - **Documentation**: [README.md](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/tree/main/examples/relayers/zama/zama-sdk/README.md) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Use a file URL for the README link.
The tree/.../README.md route returns 404; use GitHub’s blob route instead. ()
Proposed fix
-- **Documentation**: [README.md](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/tree/main/examples/relayers/zama/zama-sdk/README.md)
+- **Documentation**: [README.md](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/blob/main/examples/relayers/zama/zama-sdk/README.md)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - **Documentation**: [README.md](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/tree/main/examples/relayers/zama/zama-sdk/README.md) | |
| - **Documentation**: [README.md](https://github.com/OpenZeppelin/openzeppelin-relayer-sdk/blob/main/examples/relayers/zama/zama-sdk/README.md) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/zama-fhevm-counter-guide.mdx` at line 57, Update the README link
in the documentation list to use GitHub’s blob route instead of the tree route,
preserving the existing repository path and README.md target.
| - The OpenZeppelin Relayer's signer is used both for submitting the encrypted transaction and for signing the EIP-712 payload that the Zama SDK requires for user decryption. The same key backs both operations. | ||
| - For production, prefer a hosted signer (AWS KMS, Google Cloud KMS, Turnkey, CDP) over `local`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Require EIP-712 support in production signer recommendations.
User decryption depends on signTypedData, but the CDP signer does not implement it.
docs/guides/zama-fhevm-counter-guide.mdx#L131-L132: remove CDP and recommend only EIP-712-capable signer backends.docs/zama-fhevm.mdx#L150-L150: explicitly require hosted signers to supportsignTypedData.
📍 Affects 2 files
docs/guides/zama-fhevm-counter-guide.mdx#L131-L132(this comment)docs/zama-fhevm.mdx#L150-L150
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/zama-fhevm-counter-guide.mdx` around lines 131 - 132, The
production signer recommendations in docs/guides/zama-fhevm-counter-guide.mdx
lines 131-132 must remove CDP and list only hosted signer backends that support
EIP-712 signing, while preserving the guidance to prefer hosted signers over
local. Update docs/zama-fhevm.mdx line 150 to explicitly require hosted signers
to implement signTypedData.
| The script first attempts public decryption, then falls back to user decryption (see [Decryption Model](#decryption-model) below): | ||
|
|
||
| ```typescript | ||
| import { Speed } from '@openzeppelin/relayer-sdk'; | ||
| // Public decryption — no signature required. | ||
| const pub = await sdk.decryption.decryptPublicValues([handle]); | ||
| const value = pub.clearValues[handle]; // bigint | undefined | ||
|
|
||
| // User decryption — the SDK builds the EIP-712 request, has the OZ Relayer | ||
| // (our signer) authorize it, and caches the decrypt session in storage. | ||
| const result = await sdk.decryption.decryptValues([{ encryptedValue: handle, contractAddress }]); | ||
| const clear = result[handle]; // bigint | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Implement the documented public-to-user decryption fallback.
The snippet always invokes user decryption after public decryption, and an expected public-decryption error may prevent fallback entirely. Only call decryptValues when the handle was not publicly decrypted, while rethrowing unrelated failures.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/zama-fhevm-counter-guide.mdx` around lines 257 - 268, Update the
decryption example to use public decryption first and call
sdk.decryption.decryptValues only when pub.clearValues[handle] is undefined;
catch expected public-decryption failures to allow that fallback, but rethrow
unrelated errors. Preserve the existing public result when available and the
user-decryption result otherwise.
| - **`Public decryption failed`**: this can be expected depending on the contract and permissions. The script will then try user decryption. | ||
| - **`User decryption failed`**: check that the OpenZeppelin Relayer can sign typed data correctly and that the contract address and decryption keypair are the ones you expect. Confirm the EIP-712 `startTimeStamp` / `durationDays` window is valid. | ||
| - **Transaction polling timeout**: the transaction may still be pending, the OpenZeppelin Relayer may be unhealthy, or the target chain may be slow. Inspect `getTransactionById` directly and check OpenZeppelin Relayer logs. | ||
| - **`User decryption failed`**: check that the OpenZeppelin Relayer can sign typed data correctly, the contract is on the configured chain, and the SDK's `storage` is persisting decrypt session signatures across runs (use Redis-backed storage in production). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Do not present persistent storage as required for decryption.
The example itself uses MemoryStorage; losing cached sessions causes regeneration and extra signing, not a user-decryption failure. Reserve this advice for repeated-signing or cache-loss symptoms.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/zama-fhevm-counter-guide.mdx` at line 394, Update the “User
decryption failed” troubleshooting bullet in the Zama FHEVM counter guide to
remove persistent storage as a required decryption condition. Keep guidance
about the relayer’s typed-data signing and configured chain, and move any
MemoryStorage/Redis advice to repeated-signing or cache-loss troubleshooting
only.
Summary
This PR updates the Zama docs to use the newly released SDK as the main interaction point instead of relayer-sdk, which is a lower-level primitive SDK.
SDK PR: OpenZeppelin/openzeppelin-relayer-sdk#255
Testing Process
Checklist
Note
If you are using Relayer in your stack, consider adding your team or organization to our list of Relayer Users in the Wild!
Summary by CodeRabbit