refusedSend treats NONCE_EXPIRED as 'the node holds no such thing'. That is false for the transaction that spent the nonce. ethers maps any eth_sendRawTransaction message matching /nonce/ and /too low/ to NONCE_EXPIRED. A gateway or load-balanced RPC that retries internally (README section 4 item 1) can deliver the signed bytes and then answer 'nonce too low' about them once they are mined.

Line 269 then deletes the only record of a mined transaction, and nothing checks getTransaction/getTransactionReceipt(own) first. Two paths follow. (a) hashes becomes empty: line 277 throws NONCE_MOVED and checkpoint(state()) writes a record without the hash.

The step's receipt, gas and, for a revert, its failed entry are gone for good, so totalGas and plan+steps+failed undercount. (b) An earlier bid X is still in hashes (the delivered one Y was its replacement): NONCE_MOVED cannot fire because hashes.length>0. last is not raised (NONCE_EXPIRED is not mayHoldBid). Each later attempt signs another bid at the spent nonce, which is refused and removed in turn, and firstReceipt([X]) never returns because X was replaced.

After 8 attempts the run stops STEP_STUCK with pending.hashes=[X], even though the step landed. The next resume spends stepTimeoutMs (5 min) waiting on X, drops it, and the step shows up only in notInRecord. If Y reverted (setRevealCommit), its failed entry and gas are lost too.

So the answer to section 4 item 1 is: only a manual resume recovers, and the record is permanently incomplete.

It fails safe: no second contract, because the nonce never moves unread.

Fix: for NONCE_EXPIRED, delete own only when getTransactionReceipt(own) and getTransaction(own) both return null over visibleReads reads. If a receipt exists, treat it as this step's receipt: settled(), record() and nonce++. The bidTooLow and INSUFFICIENT_FUNDS refusals can keep the current removal.

RESUME_OUT_OF_ORDER is the guard for this case: a stale gate read says an already-landed step is not done, at the nonce where another step's transaction is waiting. Since Submission 14 the guard is skipped when a single eth_getTransactionByHash answer is null for every seed hash. A null from one backend of a load-balanced RPC shows only that this node's pool lacks the transaction.

The tool applies visibleReads elsewhere for this reason (gates, codeVisible, recordedReceipt, settled), but not here. Under the README's own lag model, a stale gate followed by one empty answer sends the already-done step again at the seed's nonce at a market bid. If that bid is refused as underpriced, last=fee and the next attempt bids 125% over it and replaces the other step's waiting transaction.

The landed step then runs a second time. addPaymentToken or approvePaidPrice repeated reverts on chain: a failed entry, burned gas, and a TX_FAILED stop, because those steps have revertRetries=0. setRevealURIs or transferOwnership repeated costs an extra transaction. The replaced step is resent later. It fails safe (read-back), but it burns gas and stops the run, which is exactly what the guard existed to prevent.

Fix: require the null answer on visibleReads consecutive reads, spaced pollMs apart, before treating the seed as unheld. Any non-null answer or RPC error resets the count. Keep the current RESUME_OUT_OF_ORDER throw otherwise.

plan+steps+failed is a valid lower bound only while every recorded entry is still mined. recordedReceipt (line 193) checks just top, the entry with the highest blockNumber. A reorg two or more blocks deep that removes the top entry and the one below it drops only the top. The lower entry stays, so plan+steps+failed is one above the real count.

With floor 0 and a correct stableNonce, Math.max picks the too-high value and the step is signed at a nonce with a gap below it. Nodes keep such a transaction queued and it never mines, so firstReceipt times out on every attempt and the run ends STEP_STUCK. Every resume repeats this, because the stale entry is never re-checked, until the reorged transaction is re-mined.

If it is never re-mined (dropped from pools, or invalid after the reorg), the run cannot progress without hand-editing the record. This answers 'is plan+steps+failed right for every record the tool can write': not when a non-top entry was reorged out. Mainnet reorgs of 2 or more blocks are rare, so this is info.

Fix: on resume, run recordedReceipt over every steps/failed entry, not only the top, or at least over every entry whose block is within a reorg window of the head. Alternatively, use plan+steps+failed only after confirming that the receipt of the entry at the highest nonce is still visible.

record() (line 142) stores rc.blockNumber/rc.blockHash from the receipt firstReceipt returned. settled() (lines 164-171) checks only that some receipt for rc.hash exists and that the head is at or above rc.blockNumber. It never checks that the receipt is still in block rc.blockNumber. The run then goes on for five more steps.

The only later re-check is on --resume, and it looks only at the single highest entry top (line 193). So if a 1-block reorg drops the block holding the deploy or addPaymentToken and the same transaction is re-included at the next height, the entry keeps the old height and nothing corrects it.

The read-back builds its expected values from that height. expect.startBlock=String(deployBlock) (line 364) is compared against the immutable startBlock=block.number the constructor wrote at the real height (contract line 246). usdcUsableAt=blockTime(addBlock)+PAYMENT_TOKEN_DELAY (line 356) is compared against the contract's block.timestamp+2 days at the real block (line 382). Both mismatch on a valid deployment.

A resume does not fix this: top is the later transferOwnership entry, so the stale deploy/add entry is never re-read, and every resume returns the same readBackMismatch. The partial file stays (line 475), the CLI exits 2, and safe-batch accept/open refuse with RECORD_HAS_MISMATCH (safe-batch.mjs line 199). The Safe cannot take ownership through the tool until someone edits the record by hand, while the deployer key keeps every owner power.

This is the 'can a real reorg stick a run' case of section 4.5. It is not in section 5's accepted list, which covers only an entry that leaves the record, not one that stays with a wrong height.

Fix: in the read-back, take deployBlock and addBlock from fresh getTransactionReceipt reads of the recorded hashes (or compare against genesis.startBlock() and the PaymentTokenAdded event block), not from the stored blockNumber. Or, on resume, re-check every steps/failed entry with recordedReceipt and rewrite blockNumber/blockHash from the receipt, not only the top one.

In send(), sent=true is set only when broadcastTransaction resolves (line 265). An error matched by mayHoldBid's held words ("already known", "known transaction", "already imported", "same hash") means the node holds this very transaction. This includes the README section 4.1 case of a gateway that delivered the transaction, retried internally and got the duplicate answer.

On that error the code sets last=fee and keeps the hash, but sent stays false. Line 279 then waits only firstReceipt(hashes,pollMs*3) (6 s at the mainnet pollMs=2000) instead of stepTimeoutMs (5 min). The next attempt beats last by 25% (fees(), line 150), so a transaction a node holds and that may be in the next block is replaced at 125% of its fee, about 6 s after it went out.

The tool's rule is to wait stepTimeoutMs before raising the bid, and this path skips it. The same happens one attempt after any broadcast whose reply was a non-refusal error (502, 429) although the node took it. That attempt has sent=false and leaves last unchanged, so the next attempt signs the same bytes and gets "already known".

The cost is a tip 25% higher than needed for each such cycle, up to the TIP_CEILING (3x today's tip), plus 2 of the 8 attempts per cycle. Each wasted attempt brings STEP_STUCK nearer.

Fix: when the error is one of mayHoldBid's held words (or any non-refusal error after a fresh hash went out), set sent=true so the receipt wait is stepTimeoutMs, the same as for a taken bid. Keep last=fee so a later replacement still clears 10%.

Section 3 gives meetSeed three outcomes for another step's waiting transaction at this nonce. The choice between 'no node holds it, go out at market' and the other two rests on one getTransaction read per hash, and .catch(()=>true) turns any failed read into 'held'. If no failed entry has this step's name, the run aborts with RESUME_OUT_OF_ORDER, which tells the operator the read was stale.

On the revert-retry path (line 284) failed always has this step's name, since the revert was just recorded, so the branch sets last=feeOf(seed.fee). The retry then bids at least 25% over a fee no node holds. If that passes the tip ceiling, fees() throws TIP_CEILING.

With hashes=[], the handler (line 273) sets sent=true and the step burns all 8 attempts into STEP_STUCK. Both outcomes are fail-safe and recoverable by another resume, so the impact is a misleading stop and, at worst, an unneeded fee raise on setRevealCommit's retry.

Fix: retry a failed getTransaction read (the file's retry() helper) and decide only on answers; keep 'held' for a non-null answer.

The comment on line 25 says the list covers Nethermind, but Nethermind's eth_sendRawTransaction (EthRpcModule.SendTx) rejects with ResultWrapper.Fail(acceptTxResult.ToString(), TransactionRejected). AcceptTxResult.ToString() is Message is null ? Code : $"{Code}, {Message}", so the JSON-RPC message is the CamelCase result name.

UnderpricedReplacementFilter returns a bare ReplacementNotAllowed, LowNonceFilter a bare OldNonce, BalanceTooLowFilter a bare InsufficientFunds for remote txs, the fee filter FeeTooLow, ..., and a duplicate AlreadyKnown. ethers v6 getRpcError maps sendRawTransaction errors only on /insufficient funds/, /nonce/+/too low/ and /replacement transaction/+/underpriced/. None of these match, so each one surfaces as UNKNOWN_ERROR whose message holds the CamelCase word.

That word matches no alternative in bidTooLow (line 26), mayHoldBid (line 28) or refusedSend (line 30). In send() (lines 267-277) this means: (a) a refused replacement leaves last where it was, so the next attempt signs the same bid again, and the bid never climbs. This is the failure finding 3 of audit 8b5de2de describes, still present for this client.

(b) A refused hash is not removed (line 269), so a never-held hash stays in the record. (c) A send at a spent nonce is never NONCE_EXPIRED, so the NONCE_MOVED stop on line 277 never fires. Section 3 item 5 relies on that stop for a stale low read now that floor starts at 0.

Instead the step burns all attempts and ends STEP_STUCK, recording never-held hashes as pending. The next resume then waits stepTimeoutMs (5 min) on them (line 207) before it moves on. Besu (RpcErrorType.java at main) shows the same gap on a smaller scale.

Its insufficient-funds refusal is 'Upfront gas cost exceeds account balance' (-32004), which ethers does not map to INSUFFICIENT_FUNDS, and 'Gas price below current base fee' matches nothing in the list. Its 'Nonce too low', 'Replacement transaction underpriced' and 'Known transaction' are matched.

Fix: match on the JSON-RPC error text case-insensitively, without depending on spaces, and include Nethermind's codes: /ReplacementNotAllowed|FeeTooLow(ToCompete)?/ in bidTooLow, /OldNonce/ and /InsufficientFunds|upfront gas cost exceeds/ in refusedSend (or map them to NONCE_EXPIRED / INSUFFICIENT_FUNDS before line 277 tests e.code), and /AlreadyKnown/ in mayHoldBid. Add CLI tests whose stand-in RPC answers with these exact Nethermind and Besu strings.

send() retries a reverted setRevealCommit up to twice (revertRetries:2, line 344) and never re-checks whether the step is already done. The contract reverts any second setRevealCommit with the same commit: _heldBefore(commit) is true once revealCommit==commit (EmberEvoGenesisCandidate.sol:312/340), so REVEAL_COMMIT_INVALID.

If the first send happened because the gate read was stale, which the tool allows on a resume once the record lost the step (README section 5: a mined entry can leave the record after a reorg while receipts lag, and notDone then decides from 3 reads), the first send reverts and both retries revert the same way. Submission 14 makes this worse: the retry path now calls meetSeed() right after record() has pushed this step into failed.

So failed.some(f=>f.name===name) (line 245) is always true on that path, RESUME_OUT_OF_ORDER can no longer fire there, and the retry takes last=feeOf(seed.fee) and bids over a live queued transaction of a later step at the new nonce. That replaces a valid transaction with one that is certain to revert.

Fix: before each revert retry, run the step's done check again (the same isDone, visibleReads reads) and return if it now says done. Alternatively, retry only when the revert reason is REVEAL_ACCEPTANCE_EXPIRED or REVEAL_ACCEPTANCE_INVALID (decode the revert data from the receipt or an eth_call at the failing block). Key meetSeed's override on a failed entry recorded before this send, not on the one this attempt just wrote.

Everywhere else the tool treats an absent answer as unproven until it repeats (codeAbsent 10 reads, notDone visibleReads, recordedReceipt visibleReads consecutive passes; the header comment at line 99 says nothing trusts one read). meetSeed decides 'no node holds the waiting transaction of another step at this nonce' from a single eth_getTransactionByHash per hash, and a null there means the step goes out at market at that nonce.

Mempools are per node and not shared, so on a load-balanced RPC one backend that never received H answers null while H is pending on others. This is exactly the case the guard exists for (README: 'normally this step's read was stale'). The step that should have stopped with RESUME_OUT_OF_ORDER is sent instead.

If its market bid is at least 10% over H, it replaces H. If the step was already done (the stale-gate case), it reverts (addPaymentToken twice and setRevealCommit twice revert) or lands a second time. Line 272-273 (TIP_CEILING) uses the same single read: one null sets last=null, so the next bid goes out at market below the held bid, is refused as underpriced, and climbs back to the ceiling, using up the 8 attempts.

waiting() writes fee:feeText(placed). At the first checkpoint (line 263) the new hash is in hashes but placed is still the previous bid. After a broadcast that the node took but whose answer was an error that is not a refusal (TIMEOUT, a 502, a gateway error), the hash stays (correct), but placed is never raised (line 265 is skipped).

So the STEP_STUCK checkpoint at line 289 records a fee lower than the held bid. On resume, line 249 sets last=placed=that older fee, and fees() bids max(market, old*1.25+1). That is exactly the bid the node already holds whenever the market has not moved.

For setRevealCommit, whose request changes on every resend (a fresh block and acceptance), the new hash with the same fee is refused 'replacement transaction underpriced', wasting one attempt. README section 5 accepts only the fee:null case (a death between checkpoints on the first bid). This case has a non-null but stale fee and also happens without a process death.

refusedSend (line 30) counts NONCE_EXPIRED as 'the node holds no such thing', and line 269 deletes the hash this attempt added. That is wrong for the transaction that spent the nonce. ethers 6.17.0 maps any eth_sendRawTransaction error whose message matches /nonce/ and /too low/ to NONCE_EXPIRED (verified with provider.getRpcError).

A gateway that retries internally (README section 4 item 1) can deliver the signed bytes and, once they are mined, answer 'nonce too low' about them. The author's test for finding 2 covers only a resend of the same bytes (fresh=false). For a fresh bid Y (a replacement after the first bid timed out, or any setRevealCommit resend, whose request changes every attempt) the hash is removed and nothing reads getTransactionReceipt(own) first.

Two outcomes. (a) hashes empty: line 277 throws NONCE_MOVED; the resume finds the step by its gate (steps) or resends it (a revert), but the receipt, gas and any failed entry of Y are gone from the record for good and plan+steps+failed undercounts.

(b) An earlier bid X is still in hashes: NONCE_MOVED cannot fire, last is not raised (NONCE_EXPIRED is not mayHoldBid), every later attempt signs another bid at the spent nonce, is refused and removed, firstReceipt([X]) never answers because X was replaced, and after 8 attempts the run stops STEP_STUCK with pending.hashes=[X].

The next resume waits stepTimeoutMs (5 min) on X at line 207, then seedLanded waits another stepTimeoutMs, before moving on; the step appears only in notInRecord. It fails safe (no second contract, no double send) but the record is permanently incomplete and the run stops and waits for nothing.

Fix: on NONCE_EXPIRED for a fresh hash, read getTransactionReceipt(own) (and getTransaction(own)) over visibleReads reads before removing it; if a receipt exists treat it as this step's receipt (settled, record, nonce++). bidTooLow and INSUFFICIENT_FUNDS can keep the removal.

Everywhere else the tool treats an absent answer as unproved until it repeats (codeAbsent 10 reads, notDone visibleReads, recordedReceipt visibleReads consecutive passes; line 100 says nothing trusts one read). meetSeed decides 'no node holds the waiting transaction of another step at this nonce' from one getTransaction per hash, and a null means this step goes out at market at that nonce.

Mempools are per node: on a load-balanced RPC a backend that never received H, or a lagging one, answers null while H is pending elsewhere. That is exactly the case the guard exists for (line 239: 'normally this step's read was stale').

The step goes out; if its market bid is at least 10% over H it replaces H, and if the step was in fact done (the stale-gate case the README's reorg exception creates) it lands as a revert (addPaymentToken and setRevealCommit refuse a repeat; revertRetries is 0 for addPaymentToken so the run stops TX_FAILED) or as a second transaction.

The opposite direction is also one read: .catch(()=>true) turns a 429/502 into 'held', which on the first call throws RESUME_OUT_OF_ORDER for a transaction no node holds, and on the revert-retry path (line 284, where failed always contains this step's name) raises last to the seed's fee so the retry bids at least 25% over a fee nobody holds; if that passes the ceiling fees() throws TIP_CEILING, hashes is empty, sent=true, and 8 attempts later the step throws.

Line 272 (TIP_CEILING held check) uses the same single read: one null sets last=null, the next bid goes out at market below the held bid, is refused as underpriced, and climbs back to the ceiling through the remaining attempts.

Fix: decide 'not held' only after visibleReads consecutive reads, spaced pollMs apart, in which every hash answers null; retry a failed read with the file's retry() helper and decide only on answers; apply the same rule at line 272.

record() (line 142) stores rc.blockNumber from the receipt firstReceipt returned. settled() (lines 164-171) only checks that some receipt for rc.hash exists and the head is at or above rc.blockNumber; it never checks the receipt is still in that block, and record() keeps the old rc. The run then goes on for up to five more steps. The only later re-check is on --resume, and it re-reads only the single highest entry top (line 193).

So when a 1-block reorg drops the block holding the deploy or addPaymentToken and the same transaction is re-included at the next height, the entry keeps the old height and nothing corrects it.

The read-back builds its expectations from that height: expect.startBlock=String(deployBlock) (line 364) against the immutable startBlock=block.number the constructor wrote at the real height (contract line 246), and usdcUsableAt=blockTime(addBlock)+PAYMENT_TOKEN_DELAY (line 356) against block.timestamp+2 days at the real block (contract line 423). Both mismatch on a valid deployment, in all 10 passes, since expect is computed once.

A resume does not fix it: top is the transferOwnership entry, so the stale entry is never re-read and every resume returns the same readBackMismatch. The partial file stays (line 475), the CLI exits 2, and safe-batch.mjs accept/open throw RECORD_HAS_MISMATCH (safe-batch.mjs line 199). The Safe cannot take ownership through the tool until the record is edited by hand, while the deployer key keeps every owner power.

This answers README section 4 item 5 ('can a real reorg now stick a run'): yes, and section 5 lists only an entry that leaves the record, not one that stays with a wrong height.

Fix: in the read-back take deployBlock and addBlock from fresh getTransactionReceipt reads of the recorded hashes (or compare against genesis.startBlock() and the PaymentTokenAdded event block), or on resume re-check every steps/failed entry with recordedReceipt and rewrite blockNumber/blockHash from the receipt, not only the top one.

sent=true is set only when broadcastTransaction resolves (line 265). An error matched by mayHoldBid's held words ('already known', 'known transaction', 'already imported', 'same hash') means the node holds exactly this transaction (verified: ethers 6.17.0 gives UNKNOWN_ERROR for 'already known' and 'Known transaction', so refusedSend is false and the hash is kept, which is right).

This is the README section 4 item 1 case of a gateway that delivered the transaction, retried internally and got the duplicate answer, and also the attempt after any broadcast that errored with a non-refusal (502, 429) although the node took it: that attempt leaves last unchanged, so the next one signs the same bytes and gets 'already known'. On that error the code sets last=fee but sent stays false, so line 279 waits firstReceipt(hashes,pollMs*3) instead of stepTimeoutMs.

The next attempt beats last by 25% (fees(), line 150), so a transaction a node holds and that may be in the next block is replaced about 6 s after it went out. The tool's rule is to wait stepTimeoutMs before raising a bid; this path skips it.

Cost: a tip 25% higher than needed per such cycle, up to TIP_CEILING (3x today's tip), and 2 of the 8 attempts per cycle, each bringing STEP_STUCK nearer.

Fix: when the error is one of mayHoldBid's held words (not a bidTooLow refusal), set sent=true so the receipt wait is stepTimeoutMs, the same as for a taken bid; keep last=fee.

Line 25 says the list covers Nethermind; README section 7 admits its constants were not read. Checked against the sources: in Nethermind 1.38.1 (AcceptTxResult.cs at that tag) the results are AlreadyKnown=new(1,nameof(AlreadyKnown)), FeeTooLow=new(3,nameof(FeeTooLow)), InsufficientFunds=new(6,nameof(InsufficientFunds)), ReplacementNotAllowed=new(11,nameof(ReplacementNotAllowed)), with ToString() => Message is null ?

Code : $"{Code}, {Message}"; EthRpcModule.SendTx returns ResultWrapper.Fail(acceptTxResult.ToString(), ErrorCodes.TransactionRejected); TxPool.AddCore returns the bare ReplacementNotAllowed, FeeTooLowFilter the bare FeeTooLow, BalanceTooLowFilter the bare InsufficientFunds for remote transactions. (OldNonce is already 'nonce too low' at 1.38.1, so NONCE_MOVED does work there; the flow specialist's OldNonce claim does not hold.)

Commit 693ab2b9 of 2026-06-30 ('align AcceptTxResult rejection messages with Geth canonical phrases'), first shipped in 1.39.0 on 2026-07-08, changed them to 'replacement transaction underpriced', 'transaction underpriced', 'already known', which the list matches; every earlier release, which an RPC provider may still run four months later, answers with the CamelCase words.

Verified with ethers 6.17.0 getRpcError and the three predicates copied from lines 26/28/30: 'ReplacementNotAllowed', 'FeeTooLow, FeePerGas needs to be higher than 5', 'AlreadyKnown', 'InsufficientFunds' all give UNKNOWN_ERROR with refusedSend=bidTooLow=mayHoldBid=false.

In send() that means: a refused replacement leaves last where it was, so the next attempt signs the same bid and the bid never climbs (the failure finding 3 describes); the refused hash is kept (line 269) as a never-held hash in the record, which the next resume waits stepTimeoutMs on at line 207; 'AlreadyKnown' does not raise last, so a resend of the same bytes loops 8 times at 6 s each.

Besu (RpcErrorType.java at main) has a smaller gap: 'Upfront gas cost exceeds account balance' (-32004) is not mapped to INSUFFICIENT_FUNDS by ethers and matches nothing, and 'Gas price below current base fee' matches nothing, while its 'Nonce too low', 'Replacement transaction underpriced', 'Known transaction' and 'Gas price below configured minimum gas price' are matched.

Fix: add /ReplacementNotAllowed|FeeTooLow/ to bidTooLow, /AlreadyKnown/ to mayHoldBid, /InsufficientFunds|upfront gas cost exceeds/ to refusedSend (case-insensitive, no spaces assumed), and add CLI tests whose stand-in RPC answers with these exact strings.

send() retries a reverted setRevealCommit up to twice (revertRetries:2, line 344) and never re-checks isDone. The contract refuses any second setRevealCommit with the same commit: _heldBefore(commit) is true once revealCommit==commit (EmberEvoGenesisCandidate.sol lines 312 and 339-340, checked before the acceptance), so every retry reverts REVEAL_COMMIT_INVALID whatever previous the retry reads.

The first send happens on a stale gate once the record lost the step (README section 5: a mined entry can leave the record after a reorg while receipts lag, and notDone then decides from 3 reads of a possibly lagging node), so the first revert is a cost the README accepts; the two retries are pure waste.

Submission 14 adds meetSeed to the retry path right after record() pushed this step into failed, so failed.some(f=>f.name===name) (line 245) is always true there: RESUME_OUT_OF_ORDER can never fire on a retry, and when another step's transaction waits at the new nonce the retry takes last=feeOf(seed.fee) and replaces that live transaction with one that is certain to revert.

Fails safe (the contract refuses the repeat, the replaced step is resent later) but burns gas three times and removes a valid waiting transaction.

Fix: before each revert retry run the step's done check again (same isDone, visibleReads reads) and return if it now says done; or retry only when the revert reason is REVEAL_ACCEPTANCE_EXPIRED or REVEAL_ACCEPTANCE_INVALID (eth_call at the failing block). Key meetSeed's override on a failed entry that existed before this send, not on the one this attempt just wrote.

plan+steps+failed is a valid lower bound only while every recorded entry is still mined. recordedReceipt checks just top. A reorg of two or more blocks that removes the top entry and the one below it (neither re-mined) drops only the top; the lower entry stays and the count is one too high.

With floor 0 and a correct stableNonce, Math.max at line 211 picks the too-high value, the lower step's gate is skipped (stepBlock finds the stale entry, line 306), and the next step is signed at a nonce with a gap below it. Nodes queue such a transaction and never mine it, so every attempt's firstReceipt times out: 8 attempts x stepTimeoutMs (40 min) with the bid climbing, then STEP_STUCK.

The specialist's claim that every resume repeats this is wrong: on the second resume the stale entry is now top, recordedReceipt drops it, nonce falls back to the real count, the lower step is resent and the queued transaction is handled as the seed. The cost is one wasted cycle and bids raised toward the ceiling for nothing; no gas is spent. Mainnet reorgs of 2+ blocks are rare.

Fix: on resume run recordedReceipt over every steps/failed entry within a reorg window of the head, or use plan+steps+failed only after the receipt of the entry at the highest nonce is confirmed visible.

waiting() writes fee:feeText(placed). At the first checkpoint (line 263) the new hash is in hashes but placed is still the previous bid. After a broadcast the node took but whose answer was a non-refusal error (TIMEOUT, 502), the hash stays (right) but placed is never raised (line 265 is skipped), so the STEP_STUCK checkpoint at line 289 records a fee lower than the held bid.

On resume line 249 sets last=placed=that older fee and fees() bids max(market, old*1.25+1), which is exactly the held bid whenever the market has not moved. For setRevealCommit, whose request changes on every resend, the new hash with the same fee is refused 'replacement transaction underpriced' and one attempt is lost; for other steps the same bytes get 'already known' and lose an attempt the same way. README section 5 accepts only the fee:null case.

Within one run the same thing self-corrects after one wasted attempt.

Fix: record the highest signed fee of any kept hash in pending.fee (or treat a kept hash after a non-refusal error as possibly held: placed=fee for record purposes).