Overview
ERC20Verifier is a role-driven ICustomVerifier implementation that enforces strict, granular permissioning over ERC20 approve and transfer function calls. It builds upon OwnedCustomVerifier, using MellowACL-style roles to validate the caller, target asset, and recipient of each operation.
This verifier is designed for use in modular vaults such as SubVault where only specific ERC20 operations should be allowed through a customizable permission matrix.
Purpose
To allow or deny ERC20approve and transfer calls based on:
- The caller (must have
CALLER_ROLE) - The asset address (must have
ASSET_ROLE) - The recipient (must have
RECIPIENT_ROLE) - Additionally:
transfermust not be for zero amountapproveallows any amountvaluesent with the call must be0- Only exact calldata is accepted (no encoding variation or garbage data)
Roles
Each permission check is mapped to a distinctbytes32 role:
These roles are expected to be configured via the
initialize() function inherited from OwnedCustomVerifier.
Contract Behavior
Constructor
- Passes initialization parameters to
OwnedCustomVerifierand disables further initializers
verifyCall Function
Summary:
Checks if a specific ERC20 call is authorized.Logic Steps:
- Pre-checks:
- Must be a zero-ETH call:
value == 0 - Calldata must be exactly 68 bytes: 4-byte selector + 32 bytes address + 32 bytes uint
where(the token address) must haveASSET_ROLEwho(the caller, usually curator) must haveCALLER_ROLE
- Must be a zero-ETH call:
- Selector Validation:
- Accepts only two ERC20 functions:
approve(address,uint256)transfer(address,uint256)
- Accepts only two ERC20 functions:
- Recipient & Amount Validation:
toaddress must haveRECIPIENT_ROLE- For
transfer:amountmust not be zero
tomust not be zero address in any case
- Exact Calldata Matching:
-
Ensures call is not forged via alternate encodings:
-
Ensures call is not forged via alternate encodings:
Returns:
trueif all checks passfalseotherwise
Security Considerations
- Prevents misuse of
approveandtransferby enforcing:- Strict role-based gating
- Zero ETH payload enforcement
- Calldata normalization to eliminate encoding ambiguity
- Ensures no contract or address receives funds or allowances without being explicitly whitelisted