Skip to content

feat(validation): reject allowlist addresses that hold no contract code - #61

Merged
pviti merged 1 commit into
v2.0.0from
feature/reject-codeless-tokens
Jul 30, 2026
Merged

feat(validation): reject allowlist addresses that hold no contract code#61
pviti merged 1 commit into
v2.0.0from
feature/reject-codeless-tokens

Conversation

@pviti

@pviti pviti commented Jul 30, 2026

Copy link
Copy Markdown
Member

From the v2.0.0 hardening pass.

The constructor accepted any non-zero, non-duplicate address into the token allowlist. An address with no contract code (a typo, or a token not yet deployed on that chain) produced a deployment whose every operation reverts — caught only at the first payment attempt, by the compiler's extcodesize guard on the high-level token calls (verified: authorize against a codeless token already reverts, so no funds were ever at risk — this is fail-fast hardening, not a vulnerability fix). Multi-chain deploys read token addresses from per-chain config, which is exactly where a wrong-chain address slips in.

Now t.code.length == 0TokenHasNoCode at deploy time. One-time constructor cost, no runtime gas impact.

Also documents the token trust boundary in the README's security model: fee-on-transfer / rebasing tokens are unsupported (charge and refund forward the exact signed amount, so a token that delivers less than it debits would settle out of other payments' escrow).

Tests: test_Constructor_RejectsAddressWithNoCode; 121 passed.

🤖 Generated with Claude Code

A typo'd or not-yet-deployed token address used to produce a deployment
whose every operation reverts — the compiler's extcodesize guard on the
high-level token calls catches the mistake, but only at the first
payment attempt. Multi-chain deploys read token addresses from
per-chain config, which is exactly where a wrong-chain address slips
in; failing in the constructor surfaces it at deploy time.

Also documents the token trust boundary explicitly in the README:
fee-on-transfer and rebasing tokens are unsupported, since charge and
refund forward the exact signed amount.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@pviti
pviti marked this pull request as ready for review July 30, 2026 14:27
@pviti
pviti merged commit 78e4594 into v2.0.0 Jul 30, 2026
1 check passed
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.

1 participant