Expose additional interface id in wrapper

[arr00]

Summary by CodeRabbit

• Bug Fixes
  • Improved interface compatibility for the ERC20 token wrapper to ensure proper standards compliance.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[netlify]

✅ Deploy Preview for confidential-tokens ready!

Name	Link
🔨 Latest commit	62b9744
🔍 Latest deploy log	https://app.netlify.com/projects/confidential-tokens/deploys/697001e30a9ec40008514a77
😎 Deploy Preview	https://deploy-preview-267--confidential-tokens.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

Added a supportsInterface method override to the ERC7984ERC20Wrapper contract that returns true for the wrapper's own interface ID and delegates other interface queries to its superclass implementation.

Changes

Cohort / File(s)	Summary
Interface Detection Override contracts/token/ERC7984/extensions/ERC7984ERC20Wrapper.sol	Added public view supportsInterface(bytes4 interfaceId) override that checks if the queried interface ID matches the wrapper's own interface and defers to superclass for other IDs

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5–10 minutes

• Verify that the wrapper's interface ID is correctly identified and returned
• Confirm proper delegation to superclass supportsInterface for non-matching interface IDs
• Check that the override signature aligns with EIP-165 and parent class expectations

Poem

🐰 A wrapper so clever, now speaks for itself,
Detecting its interface with proper finesse—
What am I? it whispers, then defers with good grace,
To ancestors wiser in protocol's place.
Hopping through standards, one method at a time!

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Expose additional interface id in wrapper' accurately describes the main change: adding a supportsInterface override in ERC7984ERC20Wrapper to expose the wrapper's interface ID.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/wrapper-165-id

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

contracts/token/ERC7984/extensions/ERC7984ERC20Wrapper.sol (1)

66-69: Align supportsInterface with the ERC7984Rwa pattern and fix NatSpec.

The supportsInterface implementation should follow the established pattern in ERC7984Rwa and the base ERC7984 contract:

1. NatSpec correction (line 66): Change /// inheritdoc IERC165 to /// @inheritdoc ERC165 (missing @ prefix and incorrect interface reference).

2. Pattern consistency (line 68): To expose a wrapper-specific ERC-165 interface ID idiomatically, introduce an IERC7984ERC20Wrapper interface describing the wrapper's public API, have this contract implement it, and use type(IERC7984ERC20Wrapper).interfaceId instead. This mirrors the approach used in ERC7984Rwa with IERC7984Rwa and makes the intent explicit.

Once IERC7984ERC20Wrapper exists:

-    /// inheritdoc IERC165
+    /// @inheritdoc ERC165
     function supportsInterface(bytes4 interfaceId) public view virtual override(ERC7984) returns (bool) {
-        return interfaceId == type(ERC7984ERC20Wrapper).interfaceId || super.supportsInterface(interfaceId);
+        return interfaceId == type(IERC7984ERC20Wrapper).interfaceId || super.supportsInterface(interfaceId);
     }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4824aa4 and a4e986f.

📒 Files selected for processing (1)

• contracts/token/ERC7984/extensions/ERC7984ERC20Wrapper.sol (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: boostsecurity - boostsecurityio/semgrep-pro
• GitHub Check: coverage
• GitHub Check: slither
• GitHub Check: tests

[melanciani]

hey @arr00 , what is the rationale behind not including finalizeUnwrap in the interface ? 🤔

[jatZama]

Maybe to clarify the context for @arr00 we need to know if the interface of the wrapper changed, because if it did, then we will need to do an upgrade to the 6 already deployed wrappers on mainnet (not a big issue for now, but better know asap before registering more wrappers, actually we already stumbled on few other issues which will require an upgrade soon, so this might also be included in same future upgrade).

[arr00]

The finalizeUnwrap function we use is certainly implementation specific—the goal is to allow all confidential wrappers of ERC-20 use this interface. I could imagine many wrappers that would prefer to have different parameters in their finalize unwrap function.

[jatZama]

OK, I understand your point. We will then remove it from our upgradeable wrapper extension ( https://github.com/zama-ai/fhevm/blob/main/protocol-contracts/confidential-wrapper/contracts/interfaces/IERC7984ERC20Wrapper.sol#L22 ) , and upgrade contracts already deployed on mainnet soon.

[melanciani]

I guess that makes sense yes, too bad we cannot highlight the 2-step nature of the unwrap process in the interface but I indeed don't seel alternatives, we'll update ours as well later then yes

[Amxx]

Why is the euint (without proof) version of the unwrap function not in the interface ?