Update IERC7943, ERC20uRWA and ERC20Restricted

[xaler5]

Sync with latest EIP state

Summary by CodeRabbit

• Refactor
  • Standardized parameter naming and function return semantics across token interfaces for improved API consistency and clarity.

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

[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

The PR refactors the IERC7943 interface family and ERC20uRWA implementation to replace user-centric terminology with account-based naming, add boolean return values to mutating functions, and standardize function names for consistency across Fungible, NonFungible, and MultiToken variants.

Changes

Cohort / File(s)	Summary
Interface refactoring contracts/interfaces/IERC7943.sol	Standardized parameter naming (user → account), renamed isUserAllowed() to canTransact(), added boolean return types to forcedTransfer() and setFrozenTokens(), renamed error types (e.g., ERC7943NotAllowedUser → ERC7943CannotTransact), expanded error signatures with additional context fields, updated doc comments for new semantics across all three interface variants (Fungible, NonFungible, MultiToken).
Implementation update contracts/token/ERC20/extensions/ERC20uRWA.sol	Added new canTransact(address account) public function, updated setFrozenTokens() and forcedTransfer() to return boolean, removed prior isUserAllowed override, refactored internal references to use new function naming conventions, updated documentation.
Test update test/token/ERC20/extensions/ERC20uRWA.test.js	Updated ERC165 interface support check to reference canTransact(address) instead of isUserAllowed(address).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• Split ERC7943 into separate dedicated interfaces #216 — Directly modifies the same IERC7943 interface family and ERC20uRWA implementation with overlapping function signature and naming changes.

Suggested reviewers

• ernestognw
• cjcobb23
• frangio

Poem

🐰 With whiskers twitching, we refactor with glee,
From "user" to "account," now consistent and free,
Boolean returns on actions so true,
canTransact hops in—a hop-ful review! 🌱✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title 'Update IERC7943, ERC20uRWA and ERC20Restricted' is directly related to the main changes in the pull request, which involve refactoring these three contracts.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch update-7943

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

contracts/token/ERC20/extensions/ERC20uRWA.sol (1)

70-96: Consider renaming wasUserAllowed for consistency.

The implementation is correct and the boolean return value aligns with the interface. However, the local variable wasUserAllowed on line 90 uses the old terminology while the rest of the code has migrated to canTransact.

♻️ Optional: Rename for consistency

-        bool wasUserAllowed = canTransact(from);
-        if (!wasUserAllowed) _setRestriction(from, Restriction.ALLOWED);
+        bool couldTransact = canTransact(from);
+        if (!couldTransact) _setRestriction(from, Restriction.ALLOWED);
         _update(from, to, amount); // Explicit raw update to bypass all restrictions
-        if (!wasUserAllowed) _setRestriction(from, restriction);
+        if (!couldTransact) _setRestriction(from, restriction);

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 813f155 and b95fef0.

📒 Files selected for processing (3)

• contracts/interfaces/IERC7943.sol
• contracts/token/ERC20/extensions/ERC20uRWA.sol
• test/token/ERC20/extensions/ERC20uRWA.test.js

⏰ 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: tests-foundry
• GitHub Check: tests
• GitHub Check: coverage
• GitHub Check: slither

🔇 Additional comments (13)

test/token/ERC20/extensions/ERC20uRWA.test.js (1)

28-34: LGTM! Interface support check correctly updated.

The ERC165 interface support test now correctly references canTransact(address) instead of the old isUserAllowed(address), aligning with the account-centric API rename in IERC7943Fungible.

contracts/token/ERC20/extensions/ERC20uRWA.sol (5)

15-17: LGTM! Documentation clarifies extension scope.

The updated comment clearly communicates that derived contracts implementing mint/burn must include 7943-specific logic themselves.

---

20-24: LGTM! Clean wrapper for API migration.

The canTransact function properly delegates to the existing isUserAllowed implementation, maintaining backwards compatibility while exposing the new EIP-7943 compliant API.

---

37-39: LGTM! Consistent use of new API.

canTransfer now uses canTransact(from) and canTransact(to) consistently with the interface rename.

---

52-57: LGTM! Boolean return added per EIP-7943.

The function now returns true on success as required by the updated interface specification.

---

104-108: LGTM! Comment reference updated.

The internal comment now correctly references canTransfer terminology.

contracts/interfaces/IERC7943.sol (7)

14-21: LGTM! Account-centric terminology applied consistently.

The Frozen event and ERC7943CannotTransact error correctly use account parameter naming, aligning with the EIP-7943 terminology standardization.

---

23-33: LGTM! Error definitions are comprehensive.

The new errors ERC7943CannotTransfer and ERC7943InsufficientUnfrozenBalance provide clear, actionable information with appropriate parameters for debugging transfer failures.

---

40-49: LGTM! Boolean returns standardize mutating function signatures.

Adding returns(bool result) to forcedTransfer and setFrozenTokens follows the common ERC pattern (like ERC20's transfer) and enables better composability with external contracts.

---

51-61: LGTM! canTransact replaces isUserAllowed appropriately.

The rename from isUserAllowed to canTransact with account parameter is clearer and more semantically accurate for the permission check purpose.

---

80-99: LGTM! NonFungible interface follows same patterns.

The IERC7943NonFungible interface consistently applies account-centric terminology and the error semantics are correctly adapted for NFT context (using tokenId instead of amount where appropriate).

---

149-171: LGTM! MultiToken interface properly handles both tokenId and amount.

The IERC7943MultiToken interface correctly includes both tokenId and amount parameters in events and errors, appropriately reflecting ERC-1155 semantics.

---

179-189: LGTM! MultiToken mutating functions return bool consistently.

Both forcedTransfer and setFrozenTokens return bool result, maintaining consistency with the Fungible and NonFungible interfaces.