Skip to content

feat: add FeeToken interface#3

Open
johnletey wants to merge 1 commit intomainfrom
john/fee-token
Open

feat: add FeeToken interface#3
johnletey wants to merge 1 commit intomainfrom
john/fee-token

Conversation

@johnletey
Copy link
Copy Markdown
Member

@johnletey johnletey commented Feb 23, 2026


Open with Devin

Summary by CodeRabbit

  • New Features
    • Introduced a new token interface standard enabling tokens to support system-initiated transfer operations.

@johnletey johnletey self-assigned this Feb 23, 2026
@johnletey johnletey requested a review from a team as a code owner February 23, 2026 08:47
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Feb 23, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6feac58 and 428b16c.

📒 Files selected for processing (1)
  • src/FeeToken.sol
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/FeeToken.sol

📝 Walkthrough

Walkthrough

A new Solidity interface named FeeToken is introduced in src/FeeToken.sol. The interface defines a single external function, systemTransfer, which enables a system address to transfer tokens between specified addresses, returning a boolean result.

Changes

Cohort / File(s) Summary
FeeToken Interface
src/FeeToken.sol
Introduces new FeeToken interface with systemTransfer(address from, address to, uint256 amount) external function for system-level token transfers on Noble.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A token interface, shiny and new,
With systemTransfer to see it through,
From here to there, amounts in flight,
Noble's fee token, perfectly right!

🚥 Pre-merge checks | ✅ 3
✅ 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 'feat: add FeeToken interface' directly and concisely describes the main change: introducing a new interface named FeeToken. The title accurately reflects the changeset which adds a new Solidity interface with a systemTransfer function.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ 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 john/fee-token

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

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

Copy link
Copy Markdown

@devin-ai-integration devin-ai-integration Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.

Open in Devin Review

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
src/FeeToken.sol (2)

7-7: Consider extending IERC20 to enforce ERC20 compliance at the type level.

The NatSpec states this interface targets ERC20 tokens, but because FeeToken is standalone, the type system cannot enforce that. Extending IERC20 (e.g., from OpenZeppelin) would make it impossible to satisfy FeeToken without also satisfying ERC20, preventing partial/non-ERC20 implementations from slipping through.

♻️ Proposed interface inheritance
+import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+
-interface FeeToken {
+interface FeeToken is IERC20 {
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/FeeToken.sol` at line 7, Update the FeeToken interface to extend
OpenZeppelin's IERC20 so the compiler enforces ERC20 compliance: add the IERC20
import (e.g. from `@openzeppelin/contracts/token/ERC20/IERC20.sol`) and change the
declaration to "interface FeeToken is IERC20 { ... }" (keeping any existing
FeeToken methods). Also update any contracts implementing FeeToken to satisfy
IERC20 methods (or implement/extend an ERC20 implementation) so the new
inheritance compiles.

8-9: Complete NatSpec and clarify "system address" semantics.

The @notice references a "system address" without defining what it is, leaving implementors to guess the access-control model and creating risk of divergent or insecure implementations. Additionally, @param and @return tags are missing.

📝 Proposed NatSpec improvement
-    /// `@notice` Allows the system address to transfer tokens from one address to another.
-    function systemTransfer(address from, address to, uint256 amount) external returns (bool);
+    /// `@notice` Allows the Noble system address to transfer tokens from one address to another
+    ///         without a prior approval, as part of the fee-collection flow.
+    /// `@dev` Implementations MUST restrict callers to the privileged Noble system address.
+    ///      Reverts or returns `false` if the transfer cannot be completed.
+    /// `@param` from  The address tokens are transferred from.
+    /// `@param` to    The address tokens are transferred to.
+    /// `@param` amount The number of tokens to transfer (in the token's smallest unit).
+    /// `@return`      `true` on success, `false` on failure (consistent with ERC20 `transfer`).
+    function systemTransfer(address from, address to, uint256 amount) external returns (bool);
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/FeeToken.sol` around lines 8 - 9, Update the NatSpec for function
systemTransfer to fully document the parameters, return value, and the "system
address" semantics: add `@param` tags for from, to, and amount; add an `@return` tag
describing the boolean success value; and clarify who the "system address" is
and how access is controlled (e.g., a specific role, immutable admin address, or
contract with onlySystem modifier) and what happens on unauthorized calls or
failure; reference the function name systemTransfer and any relevant
access-control identifiers (e.g., modifier names like onlySystem, role
constants, or an immutable systemAddress) so implementors know the required
enforcement model.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/FeeToken.sol`:
- Line 7: Update the FeeToken interface to extend OpenZeppelin's IERC20 so the
compiler enforces ERC20 compliance: add the IERC20 import (e.g. from
`@openzeppelin/contracts/token/ERC20/IERC20.sol`) and change the declaration to
"interface FeeToken is IERC20 { ... }" (keeping any existing FeeToken methods).
Also update any contracts implementing FeeToken to satisfy IERC20 methods (or
implement/extend an ERC20 implementation) so the new inheritance compiles.
- Around line 8-9: Update the NatSpec for function systemTransfer to fully
document the parameters, return value, and the "system address" semantics: add
`@param` tags for from, to, and amount; add an `@return` tag describing the boolean
success value; and clarify who the "system address" is and how access is
controlled (e.g., a specific role, immutable admin address, or contract with
onlySystem modifier) and what happens on unauthorized calls or failure;
reference the function name systemTransfer and any relevant access-control
identifiers (e.g., modifier names like onlySystem, role constants, or an
immutable systemAddress) so implementors know the required enforcement model.
ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8f52294 and eb785cb.

📒 Files selected for processing (1)
  • src/FeeToken.sol

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
test/ConsensusInfo.t.sol (1)

18-18: Consider using SYSTEM_ADDRESS instead of the hardcoded literal.

The vm.prank address is identical to the newly introduced SYSTEM_ADDRESS constant. Extending the import on line 6 and using the named constant keeps this file consistent with the broader centralisation intent of this PR.

♻️ Proposed refactor
-import {CONSENSUS_INFO_ADDRESS} from "../src/Constants.sol";
+import {CONSENSUS_INFO_ADDRESS, SYSTEM_ADDRESS} from "../src/Constants.sol";
-        vm.prank(0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE);
+        vm.prank(SYSTEM_ADDRESS);
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/ConsensusInfo.t.sol` at line 18, Replace the hardcoded address literal
passed to vm.prank with the named constant SYSTEM_ADDRESS; add SYSTEM_ADDRESS to
the file's top imports so the constant is available, then update the
vm.prank(...) call to use SYSTEM_ADDRESS instead of the literal to keep
consistency with the new centralised constant.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@test/ConsensusInfo.t.sol`:
- Line 18: Replace the hardcoded address literal passed to vm.prank with the
named constant SYSTEM_ADDRESS; add SYSTEM_ADDRESS to the file's top imports so
the constant is available, then update the vm.prank(...) call to use
SYSTEM_ADDRESS instead of the literal to keep consistency with the new
centralised constant.
ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between eb785cb and 6feac58.

📒 Files selected for processing (3)
  • src/ConsensusInfo.sol
  • src/Constants.sol
  • test/ConsensusInfo.t.sol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants