send() signs first, records the hash, broadcasts, and on an error for which refusedSend(e) holds removes the hash this attempt added (line 269). NONCE_EXPIRED is treated as proof that no node took the bytes.

A load-balanced gateway that retries internally gives exactly the answer README section 4.1 describes: the first try delivers the transaction and its reply is lost, and the retry is answered 'nonce too low' because the first copy is already mined or pooled at that nonce. ethers maps any message containing 'nonce' and 'too low' to NONCE_EXPIRED. The hash is spliced out.

On the first attempt of a step, hashes is then empty, and once stableNonce() reads past the nonce, line 277 checkpoints state() with no pending entry and throws NONCE_MOVED. The record keeps no hash of the transaction that spent the nonce. Nothing checks own with getTransaction or getTransactionReceipt before deleting it, so nothing recovers it.

The resume passes only through the gate: a successful step lands in notInRecord and its gas is left out of totalGas. If the delivered transaction reverted (setRevealCommit on a low limit), its failed entry is lost, so plan+steps+failed counts one nonce short. A landed step with no recorded hash is also the precondition for the two meetSeed findings below.

When this step's nonce equals the nonce of another step's waiting transaction, the code normally means the gate read was stale, and meetSeed throws RESUME_OUT_OF_ORDER (line 245). The only bypass for a step with no failed entry is line 244: if one provider.getTransaction(h) call per recorded hash returns null, the step is sent at that nonce at market fee (last stays null).

Everywhere else this file asks for visibleReads consecutive answers against lag (settled, codeVisible, notDone, recordedReceipt). This one decision, which protects against running a done step twice, rests on a single answer from whichever backend serves it. A backend that has not imported the pooled transaction, or a pool that dropped it locally while others keep it, answers null.

If the market bid is at least 110% of the waiting bid (fees rose since the stop), the stale step replaces the later step's transaction outright. Otherwise the refusal raises last by 25% each attempt until it does. Either way the protected-against case happens: a done step runs again and the later step's transaction is evicted.

Section 3 says a held waiting transaction of another step at this nonce is outbid when 'this step has a failed entry'. The test is failed.some(f=>f.name===name), true for any revert of the step ever recorded, whether or not the step later succeeded. setRevealCommit runs with revertRetries:2, so a revert at n followed by a success at n+1 is the normal path, and the failed entry stays.

If the success at n+1 is not in steps (its hash was removed as in finding 1, or seedLanded recorded no receipt), the gate decides on a resume, and three stale reads say not done. meetSeed then finds the next step's held transaction at n+2 and a failed setRevealCommit entry. It takes last=feeOf(seed.fee), skips the RESUME_OUT_OF_ORDER guard and bids 25% over the later step's transaction, so the replacement is accepted by design.

The entries store no nonce, so the check cannot tell 'my last try reverted just below this nonce' apart from 'I reverted long ago and succeeded since'.

Finding 2 of audit 8b5de2de is fixed by signing first and keeping the hash on every answer except a refusal. refusedSend (line 30) counts NONCE_EXPIRED and INSUFFICIENT_FUNDS as refusals that prove the node holds no such thing, and line 269 drops the hash at once. Neither code proves that on the RPC the tool is written for (a load-balanced or retrying gateway, README section 4 item 1). (a) NONCE_EXPIRED: ethers maps any 'nonce ... too low' text to it.

A gateway that delivered the raw transaction to one node, lost the reply and retried after the transaction mined answers 'nonce too low' about the very transaction the record just added. The hash is spliced out, hashes is empty, stableNonce()>nonce holds and the run stops with NONCE_MOVED instead of waiting for the receipt that is one poll away.

(b) INSUFFICIENT_FUNDS: a lagging node that has not yet seen the deployer's funding answers 'insufficient funds' while another node behind the same gateway already holds the transaction (the gateway fans the retry out). The hash is removed; the next attempt only recovers it if the market is unchanged so that the identical bytes are re-signed ('already known' re-adds it); with any fee move the record never watches the held transaction again.

Consequences: the step lands with no hash in the record, is skipped by the gate on the next resume and listed in notInRecord with its gas missing from totalGas; the deploy step loses its creation hash (verify-etherscan needs it); if the held transaction reverts (setRevealCommit with an expired acceptance) the revert is not in failed, so plan+steps+failed undercounts and the meetSeed exception at line 245 ('this step's own last try reverted') is disabled for it, and a later resume meeting a queued transaction at that nonce reports RESUME_OUT_OF_ORDER until that transaction mines.

The README's own rule for this path is 'anything else keeps it, and it is watched'; these two codes do not meet the standard of 'a node answered no to this transaction: it holds no such thing'.

Fix: on NONCE_EXPIRED do not splice; first run firstReceipt([own], pollMsvisibleReads): a receipt means the hash is the one that spent the nonce (record it); no receipt means another transaction spent it and the hash can go, keeping the existing !hashes.length NONCE_MOVED gate. On INSUFFICIENT_FUNDS only drop the hash when two consecutive getBalance(owner,'latest') reads both fall below gasLimitmaxFeePerGas+value; otherwise keep the hash and treat the answer like a 502.

Every other 'absent' decision the tool takes on a resume is repeated: notDone reads visibleReads passes, codeAbsent reads 10, recordedReceipt needs visibleReads matching block answers, because one request reaches one node. meetSeed is the guard that keeps a step whose gate read was stale from being sent at the nonce of another step's waiting transaction (RESUME_OUT_OF_ORDER).

Line 244 lets the step through on a single null per hash. eth_getTransactionByHash for an unmined transaction is answered from the pool of whichever node the gateway picks; a node that has not received it by gossip yet, or a gateway that does not serve pending transactions by hash at all, answers null while another node holds it. The step is then signed and broadcast at that nonce at the market fee.

If the broadcast lands on the node that holds the other transaction it is refused as underpriced (harmless, the bid climbs); if it lands on a node that does not, both are in the network at the same nonce and either may mine.

When the sent step is a true stale-gate repeat (it already landed under a hash the record lost, which is exactly the case RESUME_OUT_OF_ORDER exists for) and it wins, the contract executes it again: addPaymentToken(USDC) and setRevealCommit revert (status 0, gas burned, entry in failed), setRevealURIs/transferOwnership succeed harmlessly, and the other step's transaction is dropped from the pool and must be resent at the next nonce.

Nothing is unrecoverable, but gas is burned and a spurious failed entry is recorded, which the guard was written to prevent, and Submission 13's acceptance of 'a stale null here' covered only the TIP_CEILING branch where the consequence is a refused bid of the same step.

Fix: treat 'no node holds it' as proved only after visibleReads consecutive all-null answers spaced pollMs apart (reuse the pattern of codeAbsent), and short-circuit to 'held' when getTransactionCount(owner,'pending') > nonce; keep the catch(()=>true) so an RPC error stays 'held'.

The exception at line 245 is meant for 'this step's own last try having reverted'. It checks only that some failed entry carries the step's name. A failed entry never leaves the record (apart from the one-per-resume reorg drop), so once a step has reverted once, every later resume treats a 'not done' gate for that step as proof that it must go out, and bids over whatever other step waits at the nonce.

That is wrong when the step did succeed after its revert and the success is simply not in steps: a success whose hash the record lost (finding 1 above, or any notInRecord case), with a lagging gate read. Then plan+steps+failed is one short, the gate says 'not done', the later step's transaction is held at that nonce, and line 245 lets the repeat through at 125% of the held fee.

The repeat replaces the live transaction, executes again and reverts (setRevealCommit: previous mismatch; addPaymentToken: token exists), burning gas and adding a second failed entry, after which the displaced step is resent.

The check should bind the revert to the current position: accept the exception only when the step's latest failed entry is the highest-nonce entry in steps+failed and that nonce is nonce-1 (nothing of this deployer landed after the revert); otherwise fall through to RESUME_OUT_OF_ORDER.

refusedSend() (line 30) counts NONCE_EXPIRED as "the node holds no such thing", and line 269 removes the hash this attempt added. That is wrong for the case section 4 item 1 of AUDIT_README asks about: a gateway that retries internally. A retried eth_sendRawTransaction of a transaction the node already mined is answered "nonce too low" by geth, reth, Erigon and Nethermind (the mined transaction is no longer in the pool, so the validation reaches the nonce check), and ethers maps that to NONCE_EXPIRED. The hash removed is the one that landed.

When it is the first attempt's hash, hashes becomes empty and line 277 ends the run as NONCE_MOVED; the resume finds the step on the chain and lists it in notInRecord (a lost gas entry, but the run ends right). When it is a replacement (attempt 2 or later), the earlier hash h1, replaced and never to be mined, stays in hashes, so line 277 never fires: every remaining attempt signs at the same nonce, is answered NONCE_EXPIRED again, and waits pollMs*3; the step ends in STEP_STUCK with pending {hashes:[h1]}. On the resume, the pending entry has no receipt and stableNonce() > its nonce, so line 207 waits the full stepTimeoutMs (5 minutes) on a hash that can never land, then drops it; the gate finds the step done and the step is reported in notInRecord with its gas missing from totalGas. If the mined replacement reverted (status 0), the failed entry is never recorded either, and planNonce+steps+failed is one short for every later resume (covered only by the nonce read).

This is a non-reorg way for a mined hash to leave the record, which section 5 lists only for two reorg cases. Nothing is sent twice (the nonce is spent), so the cost is time and an incomplete record.

Fix: on NONCE_EXPIRED do not treat the fresh hash as refused before looking for it: poll provider.getTransactionReceipt(own) (or getTransaction) over visibleReads passes and keep own when it is found; and when every hash of the step has been answered "nonce too low" and stableNonce() > nonce while firstReceipt(hashes, pollMs*visibleReads) finds nothing, stop as NONCE_MOVED even though hashes is not empty, instead of burning the remaining attempts.

AUDIT_README section 2 finding 3 says the Nethermind words were taken from "the result names" only, and section 7 says its constants were not read. Read on 2026-11-04: at release 1.31.0, src/Nethermind/Nethermind.TxPool/AcceptTxResult.cs defines FeeTooLow = new(3, nameof(FeeTooLow)), FeeTooLowToCompete = new(4, nameof(FeeTooLowToCompete)), ReplacementNotAllowed = new(11, nameof(ReplacementNotAllowed)), AlreadyKnown = new(1, nameof(AlreadyKnown)), InsufficientFunds = new(6, nameof(InsufficientFunds)); only OldNonce is "nonce too low". EthRpcModule.SendTx returns acceptTxResult.ToString() (Code, or "Code, Message") as the JSON-RPC error message, so the error text is "FeeTooLow", "ReplacementNotAllowed", "AlreadyKnown" or "InsufficientFunds": no spaces. The regexes on lines 26 and 28 need "fee too low", "could not replace", "already known"; ethers maps INSUFFICIENT_FUNDS only on /insufficient funds/. So on such a node a bid refused as too low does not raise the next bid (last stays), a held transaction is not recognised as held, and an insufficient-funds refusal keeps the hash and is watched. Nothing is sent twice and no gas is spent; the step ends in STEP_STUCK after the attempts, and a resume behaves the same while the node answers that way, so a run behind a load balancer with such a node can stall on a held bid whose fee the record does not know (fee null, or a bid placed by an earlier run).

From release 2.0.0 (published 2026-09-22) and in 2.2.2 (current, 2026-10-26) the same fields carry TxPoolErrorMessages constants: "transaction underpriced", "replacement transaction underpriced", "already known", "nonce too low" and TxErrorMessages.InsufficientFundsForGas, which the lists match. The gap is only for nodes still on 1.x. Fix: add /FeeTooLow|ReplacementNotAllowed/ to bidTooLow, /AlreadyKnown/ to mayHoldBid and /InsufficientFunds/ to refusedSend (ethers' own INSUFFICIENT_FUNDS mapping misses the bare name too), and record in section 7 that the 1.x strings were read.

Merged from audit_permissions #1, audit_math #1 and audit_flow #1 (same line, same root cause). refusedSend (line 30) counts e.code==='NONCE_EXPIRED' and 'INSUFFICIENT_FUNDS' as proof that no node holds the transaction, and line 269 then splices the hash this attempt signed.

AUDIT_README section 4 item 1 names the case where that proof fails: a gateway that retries internally delivers the raw transaction, loses the reply, retries, and gets 'nonce too low' because the first copy is already mined. ethers maps any 'nonce ... too low' text to NONCE_EXPIRED. Nothing calls getTransaction or getTransactionReceipt on own before splicing it, so nothing recovers.

(a) First attempt of a step: hashes becomes [], so at line 277 stableNonce()>nonce is true and the run throws NONCE_MOVED, and checkpoint(state()) writes no pending entry and no hash. The resume skips the step by its gate. The step then shows up in notInRecord with its gas left out of totalGas, and the deploy step loses its creation hash.

If the delivered transaction reverted (setRevealCommit), record() never adds a failed entry, so planNonce+steps+failed comes out one short on every later resume. The meetSeed exception at line 245 is then also unavailable to that step. (b) Replacement attempt (a>=1): the earlier hash h1, which was replaced and will never mine, stays in hashes.

Line 277 therefore never fires. Attempts a+1..7 each sign at the spent nonce, get NONCE_EXPIRED, splice their own hash and wait pollMs*3. The step ends in STEP_STUCK with pending.hashes=[h1].

On the resume, line 207 sees stableNonce()>s.nonce and waits the full stepTimeoutMs (5 min) on h1 before dropping it, and the step again ends in notInRecord. INSUFFICIENT_FUNDS from a lagging node behind a fan-out gateway has the same effect: the held hash is dropped, and it is only re-added if the fee is unchanged and the same bytes are signed again. Nothing is sent twice, because the nonce is spent, so the cost is an incomplete record, lost gas accounting and time.

This is a non-reorg way for a mined hash to leave the record, which section 5 does not list.

From audit_economics #1. Since hashes are pushed at line 261 before broadcastTransaction, hashes may hold a hash that no node ever received: a 502, a reset, or ethers' internal getBlockNumber failing inside broadcastTransaction is not a refusal, so the hash is kept. README section 3 item 5 says a stale low read 'sends at a spent nonce, which a node refuses' (NONCE_MOVED).

Line 277 checks only !hashes.length, though. One phantom hash keeps the stop from firing: every later attempt signs at the spent nonce, gets NONCE_EXPIRED (only its own fresh hash is spliced), and waits pollMs*3. The run ends with 'STEP_STUCK : NONCE_EXPIRED' and pending.hashes=[phantom].

The next resume's line 207 sees stableNonce()>s.nonce and waits the full stepTimeoutMs on a hash that cannot have a receipt. The TIP_CEILING branch at line 272 already asks getTransaction for each hash; line 277 does not. No gas is spent and the run ends correct.

The cost is about 6 minutes and a misleading error, in exactly the stale-read case the floor-at-0 change relies on this stop for.

Merged from audit_permissions #2 and audit_flow #2. RESUME_OUT_OF_ORDER (line 245) is the guard against a stale gate sending a done step at the nonce of another step's waiting transaction. Line 244 bypasses it on a single null answer per hash.

Every other 'absent' decision in this file needs repeated answers (notDone uses visibleReads, codeAbsent uses 10 reads, recordedReceipt uses visibleReads block answers), because one request reaches one node. A pending transaction is answered from the pool of whichever node is asked, and a node that has not received it by gossip answers null. The step then goes out at market (last stays null).

If that bid is >=110% of the waiting one, or after the refusals have raised last by 25% per attempt, it replaces the later step's transaction. A done step then runs again on chain: setRevealCommit and addPaymentToken revert, burning gas and adding a spurious failed entry. The displaced step has to be resent at the next nonce.

Preconditions: a record one short (e.g. after the line-269 finding), a stale gate over visibleReads reads, and a null from a node that lacks the pooled transaction.

Merged from audit_permissions #3 and audit_flow #3. The exception is meant for 'this step's own last try having reverted' (comment at line 240). It tests only whether some failed entry carries the step's name. record() (line 142) stores no nonce, and failed entries are never removed except by the reorg drop. setRevealCommit runs with revertRetries:2, so a revert at n followed by a success at n+1 is a normal path.

If that success is not in steps (its hash was lost as in the line-269 finding, or seedLanded found no receipt) and the gate reads stale over visibleReads, the next step's held transaction at n+2 meets the exception. last=feeOf(seed.fee) is set, the guard is skipped, and the stale step bids 125% over and replaces the live transaction. Mined, the repeat reverts (REVEAL_COMMIT_INVALID: the previous commit no longer matches), burning gas and adding a second failed entry.

The displaced step is resent.

From audit_economics #2. In the no-receipt branch, nonce is raised to the highest count read. If the count passed seed.nonce by more than one, every later entry below the new nonce disappears. nextSeed() promotes it, the state() filter at line 139 (s.nonce>=nonce) leaves it out of the checkpoint at line 229, and trimSeed() in its own notDone discards it.

Its isDone then returns true and, since seed?.name no longer matches, seedLanded is not called. Its receipt was only looked for once in the resume block (line 206, pollMs*5), before the stepTimeoutMs wait on the seed at line 216. A later transaction that landed during that wait is therefore never recorded.

It is missing from steps (or from failed, if it reverted, which makes planNonce+steps+failed one short) and only shows up in notInRecord. Section 5 accepts a live hash leaving the record only after a reorg. This path needs none.

The gates prevent a resend, so the run ends correct.

From audit_math #2. README section 2 finding 3 says only Nethermind's result names were read. Those names are written without spaces, and the regexes need spaces: /fee too low/ does not match 'FeeTooLow', there is no pattern for 'ReplacementNotAllowed', and /already known/ on line 28 does not match 'AlreadyKnown'.

Nethermind 1.x returns the result name as the JSON-RPC error message (later releases use geth-style text). ethers maps NONCE_EXPIRED and INSUFFICIENT_FUNDS only from the spaced phrases, so 'OldNonce' and 'InsufficientFunds' are not refusals either. Effects on such a node: a bid refused as too low does not raise last, so the same market bid repeats; a held bid is not recognised; a refused hash is kept; and line 277's NONCE_MOVED never fires. The step ends in STEP_STUCK.

Nothing is sent twice and no gas is spent. The code-level mismatch is certain. That Nethermind 1.x returns these exact strings is the specialist's reading and was not re-checked here.