Draft ERC defining wallet-side functions (`tokenTransfer`, `tokenApprove`, `tokenApproveForAll`, `tokenAllowance`) that move ERC-20 approval bookkeeping from token contracts into the smart contract wallet. Aimed at ERC-4337 / contract-wallet UX so users grant scoped, programmable, revocable approvals from the wallet rather than per-token.
- 01ERC-4337 smart wallets that want unified approval UX
- 02session-key wallets enforcing per-dapp token allowances
- 03subscription / recurring-payment authorizations gated by the wallet
- 04batch-approve flows during onboarding
- 05compliance wallets that must revoke approvals atomically
- pnpm add @openzeppelin/contracts
- forge install eth-infinitism/account-abstraction
Implement the ERC-7204 surface on a contract wallet that already complies with ERC-4337 / ERC-6900 / ERC-7579: `function tokenTransfer(address token, address to, uint256 amount) external returns (bool)`; `function tokenApprove(address token, address spender, uint256 amount) external returns (bool)`; `function tokenApproveForAll(address spender, bool approved) external returns (bool)`; `function tokenAllowance(address token, address spender) external view returns (uint256)`. Internally route `tokenTransfer` to `IERC20(token).transfer`, but enforce wallet-level policies first — daily caps, allowlisted spenders, session-key scopes, ERC-4337 paymaster checks. `tokenApproveForAll` is wallet-scoped (a flag the wallet honours when streaming `tokenApprove`/`tokenTransfer` calls), NOT a token-level state — never proxy it down to a non-existent ERC-20 method. Advertise `IERC7204` via ERC-165 so dapps can detect wallet-managed approvals and skip the legacy per-token `approve` round-trip.
- ⚑`tokenApproveForAll` is a wallet-policy flag — there is no underlying ERC-20 hook. Implementations that try to forward it to the token contract will revert; treat it as local state guarded by the wallet's owner/session-key logic.
- ⚑Allowance accounting still lives in the ERC-20 itself — `tokenAllowance` returns `IERC20.allowance(wallet, spender)`. If the wallet caches a different value (e.g., for session-scoped sub-allowances) it MUST document that `tokenAllowance` is the sub-allowance, not the on-chain ERC-20 allowance, or integrators will mis-spend.
- ⚑Front-running the classic ERC-20 approve race still applies: changing `tokenApprove` from non-zero to non-zero without first zeroing it lets a stale spender drain the old allowance. The wallet should auto-issue a zero-approval tx before raising, or use `increaseAllowance`/`decreaseAllowance` semantics.
- ⚑ERC-7204 is Draft and not implemented by mainstream wallets (MetaMask, Coinbase Smart Wallet, Safe). Build behind a feature flag and fall back to direct `IERC20.approve` when the wallet does not advertise `IERC7204` via ERC-165.
- ⚑ERC-4337 paymaster validation runs before the wallet's approval policy — a malicious dapp can still trigger `tokenApprove` via a UserOperation if your validator does not inspect the calldata. Parse the inner `executeBatch` calls in `validateUserOp` and reject any `tokenApprove` to a non-allowlisted spender.