On --resume, nonce comes from stableNonce() (two equal eth_getTransactionCount 'latest' reads) at line 115. The wait that is meant to stop any read from being older than the record, settled(...) on the record's last step, only runs later, at line 203 ('no read below may be older than the record'). So the nonce is the one read that wait does not cover.

A load-balanced RPC whose answering node is one block behind returns the same old count twice. stableNonce accepts that, because it checks only that two reads agree, not that the value is fresh. send() then never reads the nonce again. Each of the 8 attempts rebuilds and broadcasts at that spent nonce and gets NONCE_EXPIRED / 'nonce too low'.

The error is caught, hashes stays empty, and the loop ends at line 170: checkpoint(state({pending:{name,nonce,hashes,fee:feeText(last)}})) writes pending = {name, nonce:, hashes:[], fee:null}. That overwrites the pending seed (hashes and fee of a transaction that is really waiting) that line 195 had carried over from the record. The next resume no longer knows that transaction.

Its replacement is priced from fees(null), the market fee, and is refused as REPLACEMENT_UNDERPRICED on every attempt while the original sits in the mempool. This is the outbid the remediation added ('A resume did not outbid a transaction the stopped run left waiting'), and it is silently lost. Nothing is deployed twice or recorded wrongly, but the partial record now misleads the next run, and the run is stuck until fees move or the old transaction lands or expires.

Each 'is this step already done?' check before a send (lines 207, 209, 216, 218, 220) is one read wrapped in retry(). retry() repeats only on a thrown error; a stale but well-formed answer such as 0n, false, bytes32(0) or the empty string is accepted at once. The settled() wait at line 203 confirms that the record's last block is visible over 3 reads, but a load-balanced RPC can still answer the next eth_call from a lagging node. The README models a lag on 12% of calls.

When a lagging node answers that a done step is undone, the step is sent again at the current nonce with fees(null). For setRevealURIs (not locked), approvePaidPrice and transferOwnership the resend is harmless. For addPaymentToken it reverts on chain (TOKEN_IDENTITY_REQUIRED, paymentTokens[token]!=0); for setRevealCommit it reverts with REVEAL_COMMIT_INVALID (_heldBefore).

The reverts happen whenever eth_estimateGas also hits a lagging node, and README section 8 says that case is not modelled. The resend uses the nonce of the seeded pending step. If it has the higher fee it replaces that step's transaction, which then never lands.

The run stops with TX_FAILED, a nonce and the gas are spent, and the record loses that pending step.

The comment says 'a refusal must hold for a while before it counts', but the loop returns on the first attempt whose check does not throw. A refusal based on fresh state is therefore discarded as soon as any of the next 9 attempts, 3 s apart, reads older state. chainState also reads each of about 19 fields separately (Promise.all of steady() calls) with no common blockTag, so a single attempt mixes blocks, and only the changed field needs to come from a lagging node.

The default reader is a public load-balanced RPC (ethereum-rpc.publicnode.com). The checks exist to catch the deployer key changing the contract after the record (audit 90ae2f92 finding 6), and such a change is by definition the newest state, the state most likely to be missing from a lagging node.

This bites accept, which is run straight after the deployment while the deployer key still owns the contract. open is protected only because the deployer key has no power left once the Safe owns the contract.

On --resume the tool makes sure no read is older than the last entry of steps, then decides each step from a single state read (retry only repeats on an RPC error, not on an old value). The one transaction a killed run can leave behind is recorded in pending, not in steps, so its block is never waited for.

If that transaction has landed by the time the run resumes, the step's check reads a variable that only this pending transaction changed, and a node one block behind still shows the old value. The step is then sent again.

For the idempotent steps (setRevealURIs, approvePaidPrice, transferOwnership) that is only gas; for setRevealCommit and addPaymentToken the duplicate reverts on chain (REVEAL_COMMIT_INVALID because _heldBefore(commit) is now true; TOKEN_IDENTITY_REQUIRED because paymentTokens[USDC] != 0).

Usually estimateGas on a fresh node catches it first, so the run burns its 8 attempts (about one minute at pollMs 2000) and exits 1 with the estimate's revert as the error; when the estimate also hits the lagging node one reverted transaction is broadcast at the next nonce.

In both cases line 170 then overwrites pending with hashes:[], so the partial record loses the only reference to the hash that did land, and the finished record has no steps entry and no block for that step (the README section 6 case). The seed logic (line 151) only protects when stableNonce also comes back stale and equal to the pending nonce; with a correct nonce the pending hashes are discarded.

This contradicts the stated property that a resume sends only what the chain does not show; no double deployment or skipped step follows, so the impact is a failed resume run, a possible reverted transaction and a thinner record.

holds repeats only a refusal (a thrown check) up to 10 times; a check that passes is accepted on its first evaluation, and every value in chainState comes from one read (steady repeats only on an RPC error). So a public RPC backend one or two blocks behind can make checkAccept or checkOpen pass on state that no longer holds. Answering README question 4: yes, a stale read can pass a check it should fail.

The consequence is bounded because every such batch reverts when the Safe executes it: acceptOwnership reverts once the Safe is already owner, configureSnapshot reverts with SNAPSHOT_ALREADY_FIXED, setRevealURIs(...,true) reverts with REVEAL_URIS_LOCKED, and the Transaction Builder's MultiSend is all-or-nothing. No batch that executes successfully can come out of a stale pass, because after the Safe accepts only the Safe changes state.

The cost is an unsigned-for Safe transaction that fails and has to be rebuilt, which is the operational error the README's 'refusal must hold' comment intends to avoid, but only in one direction.

On resume the tool waits (settled) only for the block of the last step in steps[]. The transaction a killed run left in pending is not in steps[], and when it has landed since, the chain nonce read by stableNonce is current (seed.nonce !== nonce, so the seed and its hashes are dropped) while every per-step 'is it done?' read (lines 207, 209, 216, 218, 220) is one plain read through retry(), which only retries on a thrown error, never on a stale value.

A load-balanced RPC node that has not yet seen the pending transaction's block answers the old value, the tool decides the step is missing and broadcasts it again at the next nonce. For addPaymentToken the duplicate reverts on chain (paymentTokens[token] != 0 -> TOKEN_IDENTITY_REQUIRED): nonce consumed, gas burned, run stops with TX_FAILED and no pending in the partial record.

For setRevealCommit the duplicate reverts (REVEAL_COMMIT_INVALID, _heldBefore) and revertRetries:2 sends up to three reverting transactions before TX_FAILED. setRevealURIs, approvePaidPrice and transferOwnership are re-sent harmlessly (idempotent, one extra transaction each). Section 3 of AUDIT_README states that a resume no longer trusts stale reads; the pending step is the gap.

Fix: on resume, when resume.pending exists and seed.nonce < nonce, poll getTransactionReceipt over seed.hashes (as firstReceipt does) and settled() on the receipt found before any state read; additionally require each 'done?' read to agree over visibleReads consecutive reads the way settled/codeVisible do, or pass a blockTag >= the pending receipt's block to the reads.

chainState reads 19 values with steady(), which retries only when the call throws; a stale answer is accepted at once, and the reads are not pinned to one block (no blockTag, no eth_blockNumber check against the record's last block), so each value can come from a different node at a different height. holds() in the CLI likewise retries only refusals: a check that passes on a stale read passes for good.

The checks of finding 6 (checkRecord: pendingSigner, signer, revealCommit, skinCaps, maxSupply, paidPriceApproved; checkAccept: pendingOwner, snapshotConfigured, mintPaused, URIs) compare the chain with the record, and the record is exactly the state before the deployer key's later transaction, so the stale answer is the one that passes.

Consequence: the safe-accept (or safe-open) file is written for a contract the deployer key has changed since the record (a pending signer proposal, re-set URIs, re-configured caps). The open batch re-checks and the contract's own guards bound the harm (setMintPaused(false) refuses a pending signer; the batch rewrites the URIs), so impact is a misleading 'ok' at the point the tool was added to detect, not a loss.

Fix: read eth_blockNumber first, require it to be at least the record's last step block and stable over two reads (as settled() does), pass that blockTag to every read, and repeat the whole chainState twice requiring identical results before a check may pass.

unix() caps a numeric input at 10 digits (<= 9,999,999,999 < 2^40) but the ISO path returns Math.floor(Date.parse(v)/1000) with no upper bound, and openBatch only checks start >= now+6h, start >= takenAt and (without --far-opening) start <= now+60d. The contract requires start <= type(uint40).max = 1,099,511,627,775 (configureSnapshot, 'SNAPSHOT_TIME').

With --far-opening a six-digit ISO year is accepted, the owner is asked to confirm a date string such as '+040000-01-01T00:00', the .safe-open.json is written and the batch fails only when the Safe executes it, after two signatures. No funds or state at risk (the whole MultiSend reverts), but the tool's purpose is to refuse such a batch locally.

Fix: in openBatch add if(start>0xFFFFFFFFFFn ... ) i.e. if(start>1099511627775)throw Error('opening time does not fit uint40'), or bound the ISO path in unix() to 10-digit seconds like the numeric path.

Every step is gated by a single contract read wrapped in retry (lines 102-106). retry repeats only when the read THROWS; a value from a node behind the others is accepted as is. On a fresh run this is harmless (a stale answer says 'not done', which is also the truth).

On --resume it is not: settled() (line 203) only proves that three consecutive reads saw the record's last block, and the very next eth_call can still be served by a lagging node of the same load balancer, the exact RPC model the README describes (section 5 item 4).

A stale paymentTokens(USDC)==0 (line 216) resends addPaymentToken, which reverts on chain with TOKEN_IDENTITY_REQUIRED (paymentTokens[token]==0 in the contract, line 417); a stale revealCommit()==0x0 (line 209) resends setRevealCommit, which reverts with REVEAL_COMMIT_INVALID because _heldBefore(commit) is now true, and revertRetries:2 lets it do that three times, each at a new nonce. gasLimit() (line 147) calls estimateGas first, so the resend only reaches the chain when the estimate is also served by a lagging node; when the estimate is current, every one of the 8 attempts throws CALL_EXCEPTION and the run stops after ~50 s with that error instead.

Either way the run stops, a reverted transaction may be paid for, and the owner has to run RESUME again. No second contract and no skipped step can come of it (the fixed nonce and the contract gating hold), which keeps this low.

The package's own lag model hides it: lagger in tests/contract/deploy-mainnet-cli.test.mjs line 47 answers a lagging eth_call with '0x' (which ethers turns into a BAD_DATA throw that retry absorbs), never with the previous block's state, so the CLI test's resume after the 4th transaction passes with 12% lag while this path is never exercised.

Two related gaps in send make a resend stall for the whole attempt budget without ever changing what it sends. (a) last=fee is assigned only after sendTransaction succeeded (line 156).

When the node rejects the send with 'replacement transaction underpriced' (a transaction at this nonce is already in the mempool and the record does not know its fee: the hash-lost case of README section 6, or a kill in the window between sendTransaction returning and the checkpoint on line 157, which leaves the record one bump behind), fees(last) on the next attempt recomputes the very same value: up(v,prev) depends only on the market fee and the unchanged last, so attempts 2..8 repeat the identical rejected request.

(b) nonce comes from stableNonce() once (line 115). stableNonce accepts two consecutive equal reads, which two lagging nodes (or the same one twice) also give; the test's own lagger returns count-1 on 12% of reads, so both reads stale happens in about 1.4% of resumes.

A nonce one below the chain's makes every attempt fail with NONCE_EXPIRED, and nothing inside send re-reads the nonce or compares it with what the record already proves (planNonce + number of recorded steps is a hard lower bound).

Both cases end in STEP_STUCK or the raw error after 8 attempts (~1 min when the sends fail fast) and a second RESUME usually recovers from the chain, so no transaction is lost or duplicated; the cost is a stalled run and an alarming error for the owner at mainnet deploy time. README section 6 accepts the lost-hash case; the fixes below cost two lines and remove it.

Merged from audit_flow (nonce before settled) and audit_economics (last=fee only after a successful send; nonce never re-read). On --resume the nonce is taken at line 115 by stableNonce(), which accepts any two equal eth_getTransactionCount answers.

The wait that makes every other read at least as new as the record, settled() on the last recorded step at line 203, runs after it, so the nonce is the one read the record's block does not protect: a load-balanced RPC whose answering node has not seen the last recorded block returns the same old count twice. send() never reads the nonce again, and the record's own lower bound (planNonce + steps.length) is not applied.

Every attempt then sends at a spent nonce and fails with NONCE_EXPIRED; because hashes stays empty, line 170 writes pending:{name,nonce:,hashes:[],fee:null}, overwriting the seed (hashes and fee of the transaction the killed run really left waiting, line 124/195).

The next resume no longer knows that transaction: with seed.fee null, fees(null) prices the replacement at the market fee, the node answers REPLACEMENT_UNDERPRICED while the original waits in the mempool, and because last=fee at line 156 is only assigned after a successful sendTransaction, attempts 2..8 recompute the identical fee and are refused the same way.

The outbid logic added by the remediation (README section 3, 'A resume did not outbid a transaction the stopped run left waiting') is silently lost.

No second contract, no skipped step and no reverted step recorded as done (fixed nonces and the chain's own guards hold), but the README section 5 question 'leave a partial record that misleads the next run' has the answer yes, and the run is stuck until the waiting transaction lands, expires or the market fee rises above 1.1x its fee.

Fix: (1) on resume, after settled() on the last recorded step, derive the nonce as Math.max(await stableNonce(), resume.planNonce + resume.steps.length) and only then start sending; (2) on NONCE_EXPIRED re-run stableNonce() before the next attempt; (3) set last=fee before sendTransaction (or on REPLACEMENT_UNDERPRICED) so every attempt bumps 1.25x on the previous attempt; (4) at line 170 keep the seed's hashes and fee when the step's own hashes are empty, so a failed resume never thins the record.

Merged from audit_math, audit_economics, audit_flow and audit_permissions (same mechanism, same fix). On --resume settled() at line 203 proves only that the block of the last entry of steps[] is visible over visibleReads reads. The transaction a killed run left in flight is recorded in pending, not in steps[], so its block is never waited for.

Each gating read at lines 207, 209, 216, 218 and 220 is a single read through retry(), which repeats only when the read throws (line 104): a well-formed stale answer (0n, 0x0, false, old string) is accepted at once.

A load-balanced RPC can therefore answer the gate from a node behind the pending transaction's block (README section 5 item 4 names this model) and the tool resends a finished step at the next nonce: setRevealURIs, approvePaidPrice and transferOwnership are idempotent (one wasted transaction); addPaymentToken reverts on chain with TOKEN_IDENTITY_REQUIRED (contract line 417-418, paymentTokens[token] must be 0) and setRevealCommit reverts with REVEAL_COMMIT_INVALID (_heldBefore, line 312) up to three times because of revertRetries:2.

The revert reaches the chain whenever eth_estimateGas is also served by the lagging node (README section 8 says the lag model does not cover eth_estimateGas); otherwise every attempt throws at the estimate and the run stops after 8 attempts (~1 min) with that error.

In both cases the seed is dropped when its nonce differs (line 151) and line 170 rewrites pending with hashes:[], so the hash that did land is lost from the record and the finished record has no steps[] entry or block for that step (the section 6 case, now reachable by a single lagging read). If the seeded pending step has a lower fee, the resend of a different step at the same nonce (audit_flow's variant) replaces it.

No second contract and no skipped step can follow (a stale read only ever says 'not done'), so this is low. The package's lagger (tests/contract/deploy-mainnet-cli.test.mjs line 47) answers a lagging eth_call with '0x', which ethers turns into a BAD_DATA throw that retry() absorbs, so the suite never exercises a stale-but-valid answer.

Fix: on resume, when resume.pending exists, poll getTransactionReceipt over pending.hashes (firstReceipt) and settled() on the receipt before any gate read, pushing it into steps[] when status is 1; require each gate to agree over visibleReads consecutive reads, or pin the gate reads to a blockTag at or above the record's last block so a lagging node throws and retry() does its job; keep the seed's hashes in the resent step's hashes.

Merged from audit_math, audit_flow and audit_permissions.

The comment on line 159 says a refusal must hold for a while before it counts, but the loop is one-directional: a check that passes is accepted on its first evaluation, and a fresh refusal is discarded as soon as any of the next nine attempts, three seconds apart, passes. chainState (line 84-95) reads about 19 values with steady(), which retries only when the call throws (line 82), with no blockTag and no block-number check against the record, so each value may come from a different node at a different height and a single lagging value is enough.

The default reader is a public load-balanced RPC (line 35). The accept/open checks exist to catch what the deployer key did after the record (audit 90ae2f92 finding 6), and such a change is by definition the newest state, the one most likely missing from a lagging node, so the stale answer is exactly the one that equals the record and passes.

In accept mode the .safe-accept.json is written for a contract whose pendingSigner, URIs, caps or commitment the deployer key has changed since the record; in open mode a second open file can be written after the batch executed.

The harm is bounded: the contract's own guards and the all-or-nothing MultiSend make a batch built on stale state revert on chain (setMintPaused(false) refuses a pending signer, configureSnapshot refuses twice, the open batch rewrites the URIs), so the cost is a misleading 'wrote ...' / exit 0 at the point this tool was added to detect, and a Safe transaction signed by two owners that fails.

Fix: read eth_blockNumber first, require it to be at least the record's last step block and identical over two reads, pass that blockTag to every read in chainState, and make holds() require the same passing result from several consecutive chainState reads (as settled() does with visibleReads=3) while still retrying refusals.

From audit_math, reproduced. unix() caps a numeric input at exactly 10 digits (<= 9,999,999,999 < 2^40) but the ISO path returns Math.floor(Date.parse(v)/1000) with no upper bound, and openBatch (line 63-79) checks only start >= now+6h, start >= takenAt and, without --far-opening, start <= now+60d. The contract requires start <= type(uint40).max = 1,099,511,627,775 (contracts/EmberEvoGenesisCandidate.sol line 291).

JavaScript accepts expanded ISO years up to +275760, so with --far-opening a start such as '+040000-01-01T00:00:00Z' passes every local check, the owner is asked to confirm '+040000-01-01T00:00 ' and .safe-open.json is written; the batch fails only when the Safe executes it, after two signatures. No funds or state at risk (the MultiSend reverts as a whole), but audit 90ae2f92 finding 3 asked this tool to refuse an impossible opening time locally.

Fix: in openBatch add if(start>1099511627775)throw Error('the opening time does not fit uint40'), or bound the ISO path in unix() to 10-digit seconds like the numeric path.

From audit_permissions, reproduced. chainState turns a failed queryFilter('PaymentTokenAdded') into extraTokens:null plus a console.warn (lines 91-92), and checkRecord passes null. In accept mode this is the only check that would show a second payment token the deployer key added during its window (the contract has no public count, a token can never be removed, and its GOLD price is whatever the caller chose).

The warning goes to stderr once per holds() iteration while the decision (write the file, print 'wrote ...', exit 0) is the same as when the check passed, so an operator reading the last line hands the Safe an acceptance without the check having run. README section 3 states the intention that a refused range 'must not hide that it went unchecked'; the output hides it from anyone who reads only the outcome.

Fix: make extraTokens===null a refusal (LOGS_UNAVAILABLE) in accept and open, with an explicit flag such as --logs-checked-on-etherscan to proceed; query the range as fromBlock=d.startBlock to a toBlock read once, in chunks if needed.

From audit_flow, confirmed against the READ ABI (lines 26-30) and the contract. The accept/open checks exist to catch what the deployer key did after the record (finding 6 of audit 90ae2f92). chainState reads owner, pendingOwner, snapshotConfigured, mintPaused, revealURIsLocked, the URIs, revealCommit, the signers, maxSupply, the six skinCaps, paidPriceApproved and the PaymentTokenAdded count.

It does not read tokenURIsLocked or supplyLocked (contract lines 148-149, bool public), both one-way owner switches (lockTokenURIs line 439, lockSupply line 273) that the record does not store. lockSupply at the reviewed caps is harmless; lockTokenURIs() permanently removes the owner's setTokenURI override (line 433 requires !tokenURIsLocked) and neither accept nor open would show it.

Fix: add both getters to READ, read them in chainState and refuse in checkRecord when either is true (the record's expected value is false for both).

From audit_economics, confirmed. README section 5 item 5 asks whether a secret reaches a child process that does not need it. Line 66 sets $env:DEPLOYER_PRIVATE_KEY process-wide and only the finally block (line 109) removes it, so the PREFLIGHT_ONLY run at line 78 inherits the key and deploy-mainnet.mjs line 323 constructs a Wallet from it even though preflight() takes only an address, which the script already holds in $deployer (line 70).

The key is therefore in three node processes (validation one-liner, pre-check, deploy) where one would do, and in the PowerShell environment through the interactive 'Type DEPLOY' wait. Nothing prints it (redact and the CLI test's secret scan were checked), so this is exposure surface, not a leak.

Fix: in PREFLIGHT_ONLY mode let deploy-mainnet.mjs accept DEPLOYER_ADDRESS instead of the key, and set $env:DEPLOYER_PRIVATE_KEY only around the deploy call at line 102, the way RPC_URL is already scoped.

From audit_permissions, confirmed. The free route reads snapshotRoot inside the same Promise.all as snapshotConfigured, so ethers batches both into one JSON-RPC request answered by one backend; the paid route reads it in a separate call after that batch resolved (line 96 against line 91-93).

The position of the check answers README question 7 correctly (after MINT_NOT_READY, before MINT_PAUSED, like the free route), and once the opening block is visible on every backend it cannot stop a valid order because the root is set once.

In the minutes around the open batch, however, a load-balanced RPC can answer configured=true from one backend and snapshotRoot=0x0 from a lagging one, and the order fails SNAPSHOT_MISMATCH (503, the 'stale Worker' code) rather than MINT_NOT_READY. Transient, the client retries, but it misreports the cause to the operator watching the Worker.

Fix: add c.snapshotRoot() to the Promise.all at line 91 (read unconditionally, as the free route does) and compare the batched value.