The check that a node is 'past the block' (eth_blockNumber) and the receipt lookup (eth_getTransactionReceipt per hash) are separate JSON-RPC requests. A load-balanced RPC sends each one to any backend. So a fresh backend can answer the head while a backend behind top.blockNumber answers the receipt.

A node that has not seen a transaction returns null, not an error, so answered stays true and empty grows. If the last visibleReads (3) of the 90 iterations happen this way, recordedReceipt returns null. Line 179 then splices the entry, topLeft=true, and the checkpoint at line 277 writes the record without it.

The entry is lost for good: notDone() returns false on a done gate without recording anything, so no later resume puts the step's hashes, gasUsed or blockNumber back. totalGas is undercounted, and stepBlock() no longer bounds that step. If it was addPaymentToken, the usableAt cross-check at line 330 is skipped. The drop also sets floor=0 and lowers planNonce+steps+failed by one.

A stale stableNonce in the same resume then sends the next step at a spent nonce (NONCE_EXPIRED, then NONCE_MOVED), and that checkpoint also discards any pending seed (see the separate finding). The package's own test only covers a node that is behind on both reads together (eth_blockNumber scripted to top.blockNumber-1). The package's own lag model, lagger() in tests/contract/deploy-mainnet-cli.test.mjs, routes every request on its own and makes this split.

Fix: drop an entry only when a reorg is proven. Store rc.blockHash in record(). On resume, read eth_getBlockByNumber(top.blockNumber) twice with the same hash, and drop only if that hash differs from the recorded blockHash and no recorded hash has a receipt whose blockHash is canonical.

Otherwise throw RECEIPT_NOT_VISIBLE, as for a node behind.

mayHoldBid (line 26) now counts TIMEOUT as 'a bid may be held', and the next bid is raised past it. The transaction was signed locally, though, and may have reached the pool, and its hash is only pushed into hashes after sendTransaction returns. When eth_sendRawTransaction times out (ethers' default request timeout is 300 s), that transaction is often mined while the tool waits.

From then on every attempt at this nonce fails with NONCE_EXPIRED. Line 230 converts that to NONCE_MOVED only when hashes is empty. Otherwise firstReceipt keeps watching only the earlier hashes.

After attempts (8) tries the step ends in STEP_STUCK, although it landed, and the checkpoint at line 242 writes a pending entry without the landed hash. The next resume recovers through the gate, but the step's receipt is never recorded: gas is undercounted, and for addPaymentToken the usableAt check at line 330 is skipped.

Fix: sign first (const signed=await deployer.signTransaction(await deployer.populateTransaction({...req,gasLimit:limit,nonce,...fee}))), push ethers.keccak256(signed) into hashes and checkpoint, then broadcastTransaction(signed). A TIMEOUT or 'already known' then leaves the held transaction watched by firstReceipt.

Each raise is fixed at 25% (line 134: prev125/100+1), but a node needs only +10% on both maxPriorityFeePerGas and maxFeePerGas to accept a replacement. When the 25% raise passes the ceiling, fees() throws instead of bidding the ceiling, even when ceiling >= prev1.1. The handler at lines 223-226 then only waits for the held transaction.

If that transaction is unmineable because its maxFeePerGas is below the current base fee, the step ends in STEP_STUCK after 8 x 5 min and every resume repeats it. A replacement under the ceiling, with a fresh maxFeePerGas (2 x base + tip), would have been mined. Section 5 accepts this only for a transaction 'at the ceiling'.

Here it hits one up to 25% below it.

Fix: when up(tip,prev) > ceiling but prev110n/100n+1n <= ceiling, bid maxPriorityFeePerGas = ceiling, keeping maxFeePerGas = max(market, prev110/100+1). Throw TIP_CEILING only when even the 10% raise passes the ceiling.

New code in section 3: after a drop (topLeft) the floor ignores seed.nonce, so nonce < seed.nonce and the seed stays in memory while an earlier step refills the freed nonce. Every checkpoint inside send() for that earlier step drops the seed's pending entry. Line 220 writes state(waiting()), which holds the current step's pending.

Lines 230 and 235 write state() with no pending. Only the in-memory seed still knows the later step's hashes and fee. If the run stops before that later step is reached (STEP_STUCK or TIP_CEILING on the refilled step, RECEIPT_NOT_VISIBLE in settled, a kill), the next resume has no seed.

It does not watch the old hashes, does not bid over the old fee, and does not record that transaction when it lands. For setRevealCommit, a late landing after more than 256 blocks reverts and spends a nonce that never reaches failed[].

Fix: in send(), write pending as the current step's waiting entry plus the outstanding seed, for example pending:[...] or an extra queued field. Make the state() calls at lines 230 and 235 keep seed while seed.nonce > nonce.

seedLanded() runs only after a gate read said the waiting step is done (notDone, line 261) or the code check found the contract (line 282).

If no receipt for seed.hashes arrives within stepTimeoutMs, the new branch sets nonce = max(stableNonce(), planNonce+steps+failed) and discards both bounds the run already had: the current nonce and seed.nonce+1. stableNonce() accepts two equal 'latest' counts, and a lagging node in the tools' own model (tests/contract/deploy-mainnet-cli.test.mjs lagger, and the finding-3 tests that script stale eth_getTransactionCount) returns two equal old counts.

The record cannot cover the gap either: a step that landed under a hash the run never saw (the only reason this branch exists) is in neither steps[] nor failed[], so planNonce+steps+failed is at most seed.nonce. The result is a nonce at or below seed.nonce, which the gate's own answer shows is already spent. Submission 12 used seed.nonce+1, which is right in exactly this case.

The README (section 3) gives the reason for the change: a step that landed at some other nonce. That reason does not need the bound to go away. A nonce that only lagging nodes report too low should be read again until it agrees, and the value kept should not drop below what the run already holds.

The send that follows cannot do harm, because the nonce is spent: it gets NONCE_EXPIRED, and send() throws NONCE_MOVED if the second stableNonce() read is fresh. If that read is stale too, all attempts fail on NONCE_EXPIRED and the run throws. Either way a valid resume stops and a person has to run it again, even though the chain had already settled the question.

Partial answer to section 4 question 3: on the no-receipt branch the nonce is not right when one read comes from a lagging node.

The drop condition is that, in the last visibleReads polls, eth_blockNumber was >= top.blockNumber and every eth_getTransactionReceipt returned null without an error. These are separate HTTP requests. On a load-balanced or method-routed RPC, the node that reported the height is not the node that answered the receipt reads.

So 'answered' does not show that a node holding the block lacked the receipt. The run only needs no receipt for the whole visibleTries*pollMs window (90 polls, about 3 minutes). That happens when receipt calls are served by a backend whose receipt index is behind, or has a gap for that block, while eth_blockNumber comes from a head tracker that is current.

Several providers route methods this way, and a node still building its tx index can return null rather than an error. Random per-request lag does not reach the drop, but routing that persists does.

What is lost: a steps[] entry is recovered by its gate, because the chain still shows the state. A failed[] entry has no gate, so once dropped it never comes back. totalGas no longer includes the gas that reverted transaction burned, and the count part of the nonce floor (planNonce+steps+failed) falls by one. That count is the guard the finding-3 fix added against stale nonce reads, for example PLANNED_NONCE_USED after a reverted deploy.

The record is checkpointed without the entry at line 277, so every later resume has lost it too. This answers section 4 question 1: yes, an entry can leave while still on the chain, and for failed[] the gates cannot recover it.

Finding 5 of audit 161d71af is fixed by raising the bid only on errors that can mean a node already holds a bid. The list is geth's wording: ethers' REPLACEMENT_UNDERPRICED (its regex needs both 'replacement transaction' and 'underpriced'), TIMEOUT, and /already known|known transaction|underpriced/.

Nethermind, Erigon and Besu use the same strings, but reth (common behind public and load-balanced RPCs) answers a refused replacement with 'insufficient gas price to replace existing transaction', a duplicate with 'already imported', and a tip under its configured minimum with 'transaction priority fee below minimum required priority fee N' (crates/transaction-pool/src/error.rs).

None of these match, ethers maps them to UNKNOWN_ERROR ('could not coalesce error (error={...message...})'), so mayHoldBid is false and last is not raised.

The paths that depend on the climb are exactly the ones Submission 13 added: after the ceiling branch sets last=null because getTransaction answered null (section 3, bullet 2: 'the bids climb again up to the ceiling'), and a resumed record whose waiting transaction is held under a hash the record does not know (a TIMEOUT send).

On reth the same market bid is refused on every remaining attempt, each followed by the 6 s receipt poll, and send() ends in STEP_STUCK; every resume repeats it while the node holds the earlier bid. The run is stalled, not broken: it clears when that transaction mines or is evicted.

Fix: widen the test to the client wordings, e.g. /already known|known transaction|already imported|underpriced|insufficient gas price to replace|priority fee below minimum/i, and add a CLI test that scripts eth_sendRawTransaction to answer {code:-32000,message:'insufficient gas price to replace existing transaction'} and asserts the next bid is higher.

Answer to section 4 questions 1 and 2. recordedReceipt returns null only after visibleTries (90) polls with no receipt for any recorded hash and the last visibleReads (3) polls answered from a head at or past the entry's block.

On a single node that is impossible for a transaction that is on the chain, and on a load-balanced RPC it needs every receipt read for 3 minutes to come from a node behind the block while the head reads come from a node past it: unlikely, but it is the one model the tool documents (a split backend).

When it happens the entry leaves the record and, with the new line 182, the waiting transaction's nonce no longer bounds the resume: floor=0 and planNonce+steps.length+failed.length is one short, so nonce comes from stableNonce alone. Two equal stale nonce reads then set nonce to the dropped step's own nonce.

The dropped step's gate (fresh node) says done, so the run goes on to the waiting step at that stale nonce; because seed.nonce is one higher, send() neither throws RESUME_OUT_OF_ORDER nor reuses the seed's hashes, the node answers 'nonce too low', and line 230 checkpoints state() without the pending entry before throwing NONCE_MOVED. The record now lacks both the dropped step and the waiting transaction's hashes and fee.

The next resume still cannot deploy twice or skip a step (the gates decide from the chain, the step lands under the forgotten hash or is replaced), but it costs up to one stepTimeoutMs wait per attempt and the final record loses that step's hash, gasUsed and blockNumber, which safe-batch's recordBlock and the read-back's usdcUsableAt check then do without.

Suggested fix: keep the seed's hashes when NONCE_MOVED is thrown (checkpoint(state(seed?{pending:seed}:{})) at line 230), and when the top is dropped keep floor at seed.nonce-1 for a seed whose nonce is the dropped entry's nonce+1 instead of 0, so the stale nonce cannot go below the step that must fill the gap.

The hash of a step's transaction enters hashes (and so the checkpointed pending.hashes, recordedReceipt, firstReceipt, seedLanded and the held check) only when deployer.sendTransaction returns. deployer is an ethers Wallet: it signs locally, so the hash is known before eth_sendRawTransaction goes out, but it is thrown away when the RPC call fails after the node accepted the transaction (a TIMEOUT, a 502 on the response, a dropped connection).

That is exactly the 'lost hash' class the README accepts in section 5, but here it is created by the tool's own send path rather than by the chain.

Consequences on this code: mayHoldBid raises last for a TIMEOUT, so attempt a+1 sends a 25% higher replacement at the same nonce; if the first transaction is mined before that, the replacement gets NONCE_EXPIRED with hashes empty and stableNonce()>nonce, and the run stops with NONCE_MOVED after a step that in fact succeeded.

On the resume the gate says done and the step is skipped, but it never enters steps: stepBlock(name) stays undefined, totalGas and recordBlock miss it, and for addPaymentToken(USDC, 1600 GOLD) the read-back check of paymentTokens(USDC).usableAt is silently skipped (addBlock undefined gives usdcUsableAt=null).

For a 502 (not mayHoldBid) the next attempt re-sends the same payload at the same fee: geth/Nethermind answer 'already known', which raises the bid and gets a replacement out, so the first transaction is replaced and paid for twice in bidding rather than waited for.

The first bid is exactly eth_maxPriorityFeePerGas from the deploy RPC and every later bid is +25% over the last placed or refused one, only after a 5-minute stepTimeoutMs or a refusal. The ceiling (max(3x suggestion, 2 gwei)) is fine, but there is no floor on the starting tip, so the number of attempts needed to reach a tip builders include is governed by the RPC's estimate.

Geth's gas-price oracle suggests the 60th percentile of the lowest tip in each of the last 20 blocks, which on mainnet is often around 0.01 gwei; ethers only substitutes 1 gwei when the RPC has no eth_maxPriorityFeePerGas at all.

Numbers: suggestion 1e7 wei (0.01 gwei): bids 1e7, 1.25e7, 1.56e7, 1.95e7, 2.44e7, 3.05e7, 3.81e7, 4.77e7 over attempts=8 (up to 40 minutes), then STEP_STUCK; the next resume starts from pending.fee and adds 8 more; reaching 1 gwei takes 21 bumps, i.e. three runs and about two hours, while the ceiling (2 gwei) is never the limit.

The run is not blocked for good, but the README's question 'is the ceiling too low to get a transaction mined' has the answer at the other end of the range: the start, not the ceiling.

EXTRA_TOKEN_COUNT_SLOT=11 is correct for the reviewed build (ERC721 slots 0-5, Ownable _owner 6, Ownable2Step _pendingOwner 7, EIP712 _nameFallback/_versionFallback 8-9, paymentTokens 10, extraPaymentTokenCount 11; linearisation ERC721, Ownable, Ownable2Step, EIP712, then the contract).

The constant is only meaningful for that layout, but chainState/checkRecord never confirm that the code at d.contract is that build: the record carries codeHash and reviewedBuild.runtimeSha256 and deploy-mainnet.mjs checks runtimeMatches on every resume, while safe-batch.mjs trusts d.contract as given.

A later build that inserts one state variable before extraPaymentTokenCount moves the count to slot 12 and makes slot 11 the mapping base of paymentTokens (always 0): accept/open then stop with CHAIN_DIFFERS_FROM_RECORD extraTokens on a correct contract, and a build that removes a variable reads paidOrderTokenId's base, also 0. Fail-safe today, but the stop message blames the deployer key.

The check is one keccak256(getCode) compare against d.codeHash (or runtimeMatches against the reviewed runtime hash) before the slot read.

Answer to README question 1, 'what does a later resume lose'. When recordedReceipt returns null for the top entry (a node past its block with none of its hashes), when seedLanded takes its no-receipt branch, or when a step landed under a lost hash, the step is never in steps: the gate skips it from the chain, which is right, but stepBlock(name) stays undefined for the rest of the run.

For addPaymentToken(USDC, 1600 GOLD) that makes addBlock undefined, usdcUsableAt null, and line 330 (if(usdcUsableAt!==null&&...)) skips the only check that paymentTokens(USDC).usableAt is the add block's timestamp plus two days; totalGas and safe-batch's recordBlock also miss the entry. The chain still holds the step and nothing is resent, so this is a loss of verification, not of state.

Only one entry can be dropped per resume, as the README says, so the loss is bounded to one step per resume.

The drop condition in recordedReceipt is built from two separate JSON-RPC requests: eth_blockNumber (line 159, answered=n>=top.blockNumber) and eth_getTransactionReceipt per hash (line 161). On a load-balanced or method-routed RPC (the one model the tool documents) the node that reported the height is not the node that answered the receipt read, so answered does not show that a node holding the block lacked the receipt.

A node that has not indexed the transaction returns null, not an error, so empty grows and after visibleTries polls with no receipt the function returns null. Note this needs every one of the visibleTries receipt reads to be null (line 162 returns on the first receipt), so random per-request lag does not reach it; persistent routing (receipt calls served by a backend whose tx index is behind or has a gap, head calls by a current head tracker) does.

Line 179 then splices the entry and line 277 checkpoints the record without it. For a steps[] entry the gate recovers the step from the chain but it is never re-recorded (notDone returns false on a done gate without recording), so stepBlock() is undefined, totalGas and safe-batch's recordBlock miss it.

For a failed[] entry there is no gate at all: the reverted transaction's gasUsed leaves totalGas for good, and the count floor planNonce+steps+failed (the guard audit 161d71af finding 3 added against stale nonce reads) drops by one. With the drop and two equal stale eth_getTransactionCount answers, the resume signs the next step at the spent nonce and depends on the node's 'nonce too low' to stop (NONCE_MOVED).

The package's own test only covers a node behind on both reads together. Merged from audit_permissions and audit_flow.

Fix: prove the absence in one request answered by one node: read eth_getBlockByNumber(top.blockNumber, true) (or by the recorded blockHash, stored in record()) and drop only when that block exists, its hash differs from the recorded one, and its transaction list holds none of top.hashes; a null block counts as 'not answered'. Otherwise throw RECEIPT_NOT_VISIBLE as for a node behind.

deployer is an ethers Wallet: the transaction is signed locally, so its hash is known before eth_sendRawTransaction goes out, but line 219 pushes tx.hash into hashes only when deployer.sendTransaction returns.

If the RPC call fails after the node accepted the transaction, the hash is lost. mayHoldBid (line 26) counts TIMEOUT as a held bid, so attempt a+1 sends a 25% higher replacement at the same nonce; when the first transaction is mined before that, the replacement gets NONCE_EXPIRED with hashes empty, stableNonce() > nonce, and line 230 throws NONCE_MOVED after a step that in fact succeeded. The checkpoint at line 230 holds no hash for the step.

On the resume the gate says done and the step is skipped, but it never enters steps: stepBlock(name) stays undefined, totalGas and the record miss it, and for addPaymentToken(USDC, 1600 GOLD) the usableAt read-back at line 330 is silently skipped. This is the 'lost hash' class the README accepts in section 5, but here the tool's own send path creates it. Merged from audit_permissions and audit_math.

Fix: populate and sign first (const signed=await deployer.signTransaction(await deployer.populateTransaction({...req,gasLimit:limit,nonce,...fee}))), push ethers.Transaction.from(signed).hash into hashes, checkpoint(state(waiting())), then provider.broadcastTransaction(signed); a broadcast error then leaves a hash the receipt logic can wait for.

The list is geth's wording: ethers' REPLACEMENT_UNDERPRICED (its regex in provider-jsonrpc.js needs both 'replacement transaction' and 'underpriced'), TIMEOUT, and /already known|known transaction|underpriced/. reth (crates/transaction-pool/src/error.rs at main, fetched 2026-11-03) answers a refused replacement with 'insufficient gas price to replace existing transaction', a duplicate with 'already imported', and a tip under its minimum with 'transaction priority fee below minimum required priority fee N'.

None of these match (only reth's generic 'transaction underpriced' does), ethers maps them to UNKNOWN_ERROR, mayHoldBid is false and last is not raised. The paths that depend on the climb are the ones Submission 13 added: the ceiling branch that sets last=null when getTransaction answered null (README section 3, 'the bids climb again up to the ceiling'), and a resume whose waiting transaction is held under a hash the record does not know.

On reth the identical market bid is refused on every remaining attempt, each followed by the receipt wait, and send() ends in STEP_STUCK; every resume repeats it while the node holds the earlier bid.

Fix: widen the test, e.g. /already known|known transaction|already imported|underpriced|insufficient gas price to replace|priority fee below minimum/i, and add a CLI test that scripts eth_sendRawTransaction to answer {code:-32000,message:'insufficient gas price to replace existing transaction'} and asserts the next bid is higher.

New code in section 3: when the top entry is dropped (topLeft) the floor ignores seed.nonce (line 182), so nonce < seed.nonce, the seed stays in memory (line 189) and an earlier step refills the freed nonce. Every checkpoint inside send() for that earlier step drops the seed's pending entry: line 220 writes state(waiting()), whose pending is the current step, and lines 230 and 235 write state() with no pending at all.

Only the in-memory seed still knows the later step's hashes, fee and gasLimit.

If the run stops before that later step is reached (STEP_STUCK or TIP_CEILING on the refilled step, RECEIPT_NOT_VISIBLE in settled, a kill, or NONCE_MOVED at line 230 after a stale nonce read sent the later step at the dropped step's nonce), the next resume has no seed: it does not watch the old hashes, does not bid over the old fee, and does not record that transaction when it lands; a market bid at that nonce is refused as underpriced while the old one is held, and for setRevealCommit a late landing after more than 256 blocks reverts and spends a nonce that never reaches failed[].

Merged from audit_permissions and audit_economics.

Fix: in send(), write the current step's waiting entry plus the outstanding seed (for example a queued field or pending as a list) whenever seed.nonce > nonce, and make the state() checkpoints at lines 230 and 235 keep the seed the same way.

Each raise is fixed at prev125/100+1 (line 134), but a node needs only +10% on both maxPriorityFeePerGas and maxFeePerGas to accept a replacement. When the 25% raise passes the ceiling, fees() throws (line 138) instead of bidding the ceiling, even when the ceiling is at least prev1.1.

The handler at lines 223 to 226 then only waits for the held transaction; if that one is unmineable because the base fee rose above its maxFeePerGas, the step ends STEP_STUCK after attempts x stepTimeoutMs and every resume with the same market fees repeats it. README section 5 accepts this only for a transaction 'at the ceiling'; here the last bid is 18.6% below it (2.44 of 3 gwei), and a replacement at 3 gwei with a fresh maxFeePerGas would have been accepted and mined.

Fix: when up(tip,prev) > ceiling but prev110n/100n+1n <= ceiling, bid maxPriorityFeePerGas = ceiling and maxFeePerGas = max(market, prev.maxFeePerGas110/100+1); throw TIP_CEILING only when even the 10% raise passes the ceiling.

seedLanded() runs only after a gate said the waiting step is done. When no receipt for seed.hashes arrives within stepTimeoutMs, line 195 sets nonce = max(stableNonce(), planNonce+steps.length+failed.length) and discards both bounds the run already had: the current nonce and seed.nonce+1. stableNonce() accepts two equal 'latest' counts, and a lagging node (the tool's own model) returns two equal old counts.

The record cannot cover the gap: a step that landed under a hash the run never saw is in neither steps[] nor failed[], so the count is at most seed.nonce. The result is a nonce at or below seed.nonce, which the gate's own answer shows is spent. Submission 12 used seed.nonce+1, which is right in exactly this case; the README's reason for the change (a step that landed at some other nonce) does not need the existing bound to go away.

The send that follows cannot do harm (NONCE_EXPIRED, then NONCE_MOVED if the next read is fresh, or NONCE_EXPIRED after all attempts) but a valid resume stops and a person has to run it again although the chain had already settled the question.

Fix: nonce = Math.max(nonce, seed.nonce+1, , planNonce+steps.length+failed.length), reading the count until a value above seed.nonce is seen (a lagging node can only report too low), and a named error if none is seen within visibleTries.

When recordedReceipt returns null for the top entry, when seedLanded takes its no-receipt branch, or when a step landed under a lost hash, the step is never in steps: the gate skips it from the chain, which is right, but stepBlock(name) stays undefined for the rest of the run.

For addPaymentToken(USDC, 1600 GOLD) that makes addBlock undefined, usdcUsableAt null, and line 330 (if(usdcUsableAt!==null&&...)) skips the only check that paymentTokens(USDC).usableAt is the add block's timestamp plus two days; totalGas and safe-batch's recordBlock also miss the entry. The chain still holds the step and nothing is resent, so this is a loss of verification, not of state, bounded to one entry per resume.

Fix: when a gate says done for a step not in steps, record a hash-less entry {name, blockNumber: the block of the gate read} so stepBlock works, or derive usdcUsableAt from the chain (Number(p>>216n) must equal the timestamp of some block in the run's window plus 172,800) instead of skipping the check when addBlock is unknown.

EXTRA_TOKEN_COUNT_SLOT=11 is correct for the reviewed build: compiling build/standard-input.json's sources with solc 0.8.38 (via-IR, 200 runs, cancun) gives _owner 6, _pendingOwner 7, _nameFallback 8, _versionFallback 9, paymentTokens 10, extraPaymentTokenCount 11 (forge inspect storageLayout, verified during this review).

The constant is only meaningful for that layout, but chainState/checkRecord never confirm that the code at d.contract is that build: the record carries codeHash and reviewedBuild.runtimeSha256, and deploy-mainnet.mjs checks runtimeMatches on every resume, while safe-batch.mjs trusts d.contract as given.

A build that inserts one state variable before extraPaymentTokenCount moves the count to slot 12 and makes slot 11 the mapping base of paymentTokens (always 0): accept/open then stop with 'CHAIN_DIFFERS_FROM_RECORD extraTokens: the deployer key changed the contract' on a correct contract, blaming the deployer key. Fail-safe today, and an answer to README question 4: the one thing still needed is to tie the slot read to the code.

Fix: in chainState read provider.getCode(d.contract,head), compare ethers.keccak256(code) with d.codeHash (and runtimeMatches against the reviewed runtime when the build is available) and throw CODE_NOT_RECORDED_BUILD otherwise; keep the slot constant next to the pinned build hash so a re-compile has to change both.