Audit 358f7f40 finding 5 is remediated by refusing accept/open when the PaymentTokenAdded range cannot be read (checkRecord, line 113) and by chunking the read in 10,000-block pieces from the deploy block (tokenLogs, line 97; from=d.startBlock, line 107). AUDIT_README section 5 says only an RPC 'whose log limit is under 10,000 blocks' would hit this and that the default RPC was not tried. I tried it.

The default RPC https://ethereum-rpc.publicnode.com does not limit the width of a range: it refuses any eth_getLogs whose fromBlock is more than about 10,000 blocks behind its head (about 33 hours) with JSON-RPC error -32602 'Archive requests require a personal token', and it refuses pinned eth_call at a block 128 or more behind head with the same error.

Measured on 2026-11-03 at head 26,332,474: an 11-block window starting 9,999 blocks back answers []; the same window starting 10,050, 10,500, 11,000, 12,000, 14,000 and 17,000 blocks back is refused; eth_call 100 blocks back answers, 128/140/160 back is refused.

Consequence for the tool as shipped: tokenLogs always starts its first chunk at the deploy block, so on the default RPC every open (which by the owner's own plan runs days or weeks after the deploy: metadata host, Worker, final free list are not built yet, USDC is usable only two days later) and every accept run more than ~33 hours after the deploy fails all 5 steady retries, extraTokens becomes null, checkRecord throws LOGS_UNAVAILABLE and holds rethrows it at once.

The documented way on is --logs-checked-on-etherscan, which makes s.extraTokens===null pass with no on-chain check at all: the very check finding 5 asked for (that the deployer key, which holds every owner power until the Safe accepts, added no second token) is bypassed in the normal case, and the flag the README calls 'for that case only' becomes the routine path. status mode additionally prints extraTokens: null with no warning (the Submission 11 console.warn was removed), so an owner looking at status before signing sees nothing wrong.

The chunk loop also makes it worse rather than better on this RPC: the refused call is the first one, so chunking never helps, and holds ends by throwing the raw ethers SERVER_ERROR rather than a named stop if the error reaches it through another path.

The pinned eth_call window (128 blocks) is not a problem for the code as written, because high is re-read right before each pass, but it is the same mechanism and rules out any future 'read at the record's block' use of this RPC.

The resume order (fix for findings 1 and 2) first waits for the record's last step with settled(steps.at(-1)), which needs getTransactionReceipt(step.hash) to be non-null on 3 consecutive reads and throws RECEIPT_NOT_VISIBLE after visibleTries (90 x 2 s = 3 minutes). A recorded step only ever holds one hash: the one whose receipt firstReceipt saw first (line 197).

The tool itself creates competing transactions for one step: after stepTimeoutMs an attempt resends the same step at the same nonce with a 25% higher fee, so h1 and h2 (and up to 8) are in mempools at once.

If h1 is mined, seen by settled (three reads within about 6 s, inside one slot), pushed into steps[], and the block is then dropped by a one-block reorg while the next builder takes the better-paying h2, the step is done on chain under h2 but the record names h1, whose receipt will never exist. The same state arises from any reorg that re-includes a step under a different hash.

If the run was killed before the next step (the window the resume exists for), every later --resume runs line 150 first: 3 minutes of polling, then RECEIPT_NOT_VISIBLE 0x<h1> and exit 1, before codeAbsent, the gates, NONCE_MOVED or the read-back are reached. deploy-mainnet.ps1 line 112 tells the owner to 'run this script again: it offers RESUME', which loops on the same stop. AUDIT_README section 5 states 'A recorded step that a reorg removes is not resent.

If it does not land again, the read-back reports a mismatch and a person must check' - but a resume never reaches the read-back in this state, and nothing in the package says what the person should change (deleting the last steps[] entry by hand is the only way on, and the README warns elsewhere against editing records). This is a liveness defect in the resume path (question 3/4 of the brief), not a fund or ownership risk: nothing is sent and no second contract can appear.

The fallback treats every failed estimate as 'the node simulated on top of the waiting transaction' as soon as this step already has a hash. It does not distinguish that case from a call that also reverts on the canonical latest state.

For the four fixed-calldata steps this is harmless: the replacement is byte-identical to the waiting one and the shared nonce makes them exclusive. setRevealCommit is different: request() rebuilds the payload on every attempt (recentBlock(), a fresh acceptance over block.number and block.hash, previous=revealCommit(), signerEpoch).

The contract checks blockhash(blockNumber) against the signed hash (EmberEvoGenesisCandidate.sol:318-321), so an acceptance built from a block that is not canonical reverts with REVEAL_ACCEPTANCE_INVALID. recentBlock() only requires two reads of the same hash, which one node on a short fork answers consistently.

In that state the estimate reverts for a real reason, the fallback sends the reverting call anyway at >=1.25x the waiting transaction's fee and 1,000,000 gas, the higher bid displaces the valid waiting h1 in the mempool, is mined, reverts, and the nonce is spent. The valid h1 can never land. revertRetries then costs a further nonce and gas, and if the forked node keeps answering, TX_FAILED stops the run.

Without the fallback the estimate would have refused h2 and h1 would have landed.

Fix: before returning REPLACEMENT_GAS, simulate the request against the canonical head explicitly, e.g. await provider.call({...req,from:owner},'latest') (ethers sends eth_call with blockTag latest, which never includes pending transactions); use the fixed limit only when that call succeeds, otherwise rethrow the estimate error. Alternatively limit the fallback to the four fixed-calldata steps and let setRevealCommit keep its full-estimate path.

chainState pins every eth_call to the agreed head and steady() retries each read 5 times at 1 s; a read that still fails only fails this pass, and holds() runs up to 10 passes with 3 s between refusals. The PaymentTokenAdded log range is the exception: tokenLogs(...).catch(()=>null) turns any failure after the 5 in-pass tries into extraTokens=null, checkRecord turns that into LOGS_UNAVAILABLE, and holds rethrows it immediately instead of treating it as one refused pass.

On a load-balanced public RPC the eth_getLogs request for [a, head] can reach a node that has not imported head yet (the head was agreed by two eth_blockNumber reads that may have come from other nodes); such nodes answer with an error for a toBlock above their head, and a node a few seconds behind stays behind for all 5 tries. The same lag on an eth_call is absorbed by holds; on the log read it is a hard stop for accept and open.

The documented workaround, --logs-checked-on-etherscan, removes the only check that the deployer key added no other payment token, so a transient refusal nudges the owner toward disabling that check.

Fix: drop the early rethrow in holds (let LOGS_UNAVAILABLE count as a refused pass like CHAIN_DIFFERS_FROM_RECORD, so it is thrown only after the 10 tries), or give tokenLogs its own retry over the refusedMs budget; keep LOGS_UNAVAILABLE as the final error when every pass fails.

$rpcUrl (line 65) and $deployerKey (line 66) are assigned in script scope outside the try/finally that begins on line 67. Inside the try every exit path, including a throw from the key check, the pre-check, the cancel prompt and the deploy call, reaches the finally, which nulls both variables and removes the environment entries; Ctrl+C inside the try also runs the finally.

The gap is the window between the two prompts and the start of the try: a stop there (Ctrl+C at the key prompt, or an exception from Read-Secret) leaves $rpcUrl, and a stop after line 66 leaves both, with nothing clearing them. When the script is run as documented (powershell -File) the process ends and the point is moot. When it is dot-sourced from an interactive session, which the header does not forbid, the plaintext URL (with its API key) stays in the session's variables.

Fix: move lines 63-66 inside the try, or wrap the whole section in the same try/finally.

last is set before sendTransaction, so any failure of the send (a 502 from the RPC, a timeout, a dropped connection) is treated as a refused bid and the next attempt bids 1.25x+1 on both maxFeePerGas and maxPriorityFeePerGas.

That is the right call for a timeout after broadcast (a lost hash must be outbid), but it also means a flaky RPC alone, with nothing in the mempool, drives the priority fee to about 4.8x the market value within one step's 8 attempts, and a resume restarts the bump chain from the recorded accepted fee, so two stuck runs can reach about 23x.

The README accepts the uncapped 4.8x for fee refusals; the network-error path and the compounding across resumes are not named. maxFeePerGas is only a cap, so the real overpay is the priority fee times the step's gas (about 170k gas for setRevealURIs): modest in ETH, but unbounded in principle.

Fix: keep the bump on every error (it is needed for the lost-hash case) but add a configured ceiling on maxPriorityFeePerGas (for example 10x the first attempt's value) and stop with STEP_STUCK when it is reached, so a person looks before more money is bid.

The stop is correct and recoverable by design, but it can repeat. On a resume the seed's landing is detected only through firstReceipt(seed.hashes) over 10 s and stableNonce() (two agreeing reads). If both are served by a node that is behind and the later gate read (notDone, which only needs one 'done' answer) is served by a fresh node, the resume sees the seed step as done, never raises nonce past seed.nonce, and the next step throws RESUME_OUT_OF_ORDER before sending.

The record is unchanged (the seed is kept by the checkpoint at line 233), so the owner re-runs; under the same lag pattern the run stops again at the same place. Nothing is sent and no funds are at risk, which is why this is informational, but the message 'run the resume again' gives no hint when a second and third run stop the same way.

Fix: when a gate says 'done' for seed.name while seed is still set, re-run firstReceipt(seed.hashes, stepTimeoutMs) and the nonce read once more before continuing, and on RESUME_OUT_OF_ORDER include the seed's hashes in the message so the owner can check them on Etherscan.

The resume prologue starts with settled(steps.at(-1)), which needs provider.getTransactionReceipt(hash) to answer for the recorded hash on visibleReads consecutive reads and otherwise throws RECEIPT_NOT_VISIBLE after visibleTriespollMs (902 s = 3 minutes). The recorded hash is the one attempt whose receipt the stopped run saw.

When a step had two attempts in flight at the same nonce (attempt 1 waited stepTimeoutMs without a receipt, attempt 2 went out at +25%), the lower-fee attempt can be the one included first and recorded; a one-block reorg can then drop that block and the builders, which hold both transactions, include the higher-fee replacement instead.

The chain state is correct (same step, same calldata; for setRevealCommit a fresh acceptance with the same commit) and the nonce is spent, but the recorded hash now has no receipt anywhere. Every subsequent --resume stops at line 150 with RECEIPT_NOT_VISIBLE before any gate, send or read-back runs.

AUDIT_README section 5 accepts a reorg-removed recorded step on the grounds that 'the read-back reports a mismatch and a person must check', but on the resume path the read-back is never reached, and the error text does not say that the record must be edited by hand. Nothing in the tool can get past this state. The same trap exists for a step entry the prologue itself pushes from seed (line 158), since the next resume treats it as steps.at(-1).

AUDIT_README section 4.1 states 'A reverted waiting transaction is not pushed, and its nonce is counted.' That holds only when the reverted transaction is found through pending (floor=Math.max(floor,seed.nonce+1), line 157). On the in-run path a reverted receipt does nonce++ (line 192) and then, when no revertRetries remain, writes checkpoint(state()) with no pending and no step entry, so the record carries nothing about the spent nonce.

On the next resume floor=planNonce+steps.length (line 151) is one below the chain's nonce, and nonce=Math.max(await stableNonce(),floor) (line 162) relies entirely on stableNonce, which is two consecutive reads that may both come from a node one block behind (the lag model this package tests against, and sticky keep-alive connections make the two reads likely to hit the same backend). The resume then sends the step at the spent nonce.

A fresh node answers NONCE_EXPIRED, which with hashes empty reaches NONCE_MOVED only if the following stableNonce() is fresh; a node that is still behind accepts the transaction into its pool and returns a hash, after which firstReceipt waits stepTimeoutMs per attempt (8 x 5 min) for a receipt that cannot exist, then STEP_STUCK, and only the resume after that reaches PLANNED_NONCE_USED or the right nonce.

No funds are lost and no second contract can be deployed (the nonce stays at planNonce for the deploy), but a reverted deploy or a reverted addPaymentToken costs an extra resume and up to ~45 minutes, and the record contradicts the documented invariant.

The resume prologue gives a waiting transaction only firstReceipt(seed.hashes,pollMs*5) (10 s) to show a receipt; if the nonce is not yet spent it keeps seed and sets nonce=seed.nonce (lines 154-163). The gates then run for the seed's own step with visibleReads reads 2 s apart (line 218), after codeAbsent/codeVisible and the RESUME_CODE/RESUME_NOT_OWNER reads, i.e. typically 10-40 s later.

A transaction that is simply still pending at the prologue and gets mined in that window makes notDone(seed.name) return false (done), but nothing advances nonce or clears seed: nonce++ happens only inside send (line 192).

The next step's send then runs the line-171 check with seed.nonce===nonce and a different name and throws RESUME_OUT_OF_ORDER, whose text ('at the nonce of addPaymentToken') tells the owner the record is out of order when the real event is that the waiting transaction landed.

When seed had no hashes (the stopped run was refused on every attempt and the nonce was later spent by a lost-hash broadcast), the check does not fire and the next step is sent at the spent nonce: NONCE_EXPIRED then NONCE_MOVED on a fresh node, or a pool-accepted transaction and 8 x stepTimeoutMs on a stale one, as in the TX_FAILED finding.

Each variant needs another --resume; the second resume finds the receipt in the prologue and proceeds, so this is time and a wrong message, not a loss, but it is a direct answer to section 4.3: the stop is reached from a valid state and the message points at the wrong cause.

Audit 358f7f40 finding 1 is answered by bounding the resume nonce from below with planNonce+steps.length and pending.nonce. That bound is only complete when every nonce the deployer spent is either a recorded step or the waiting transaction.

Two paths in send() consume a nonce without leaving either: (a) a reverted setRevealCommit under revertRetries (line 194: hashes=[];last=placed=null;continue; after nonce++), after which the retry at the next nonce is the step that enters steps[]; (b) TX_FAILED (line 195) which writes checkpoint(state()) with no pending.

In both cases the record has fewer entries than nonces spent, floor is below the true next nonce, and the resume falls back entirely on stableNonce(), which is exactly the read the finding showed can be stale twice in a row. The README's statement that a reverted transaction's nonce is counted holds only for the waiting (seed) transaction.

The consequence is bounded (NONCE_MOVED or a NONCE_EXPIRED after 8 attempts, never a second deploy or a skipped step) but it turns a resume that should progress into another stop that must be re-run until the RPC answers fresh, and if the node stays behind the run never progresses even though the record held enough information to.

To fix the 'refused sends kept the same fee' part of finding 1, last is now set before sendTransaction, so any failure of the send raises the next bid by 25%. That is right for REPLACEMENT_UNDERPRICED (a node holds a competing bid), but sendTransaction also fails for reasons that leave no bid anywhere: HTTP 5xx from the gateway, a timeout, SERVER_ERROR, INSUFFICIENT_FUNDS, or a NONCE_EXPIRED that the loop swallows while hashes is non-empty.

On those paths sent stays false, the loop waits only pollMs*3 (6 s) and retries, so seven failures fit in under a minute and the eighth attempt bids 1.25^7 = 4.77x the node's suggested maxPriorityFeePerGas and maxFeePerGas. Both are then paid in full as the tip because nothing above market is in any mempool. The README asks whether a run can overpay; it can, and the only trigger needed is a gateway hiccup, not congestion.

The recorded fee is placed, so the record is right, but the chain has already paid.

Finding 5 made a refused log range stop accept and open.

The implementation maps every error from tokenLogs to null, including transient ones (gateway timeout, 'header not found' from a node behind the pinned head, a 429 burst after the 20 parallel eth_call reads that precede it), and checkRecord then throws LOGS_UNAVAILABLE, which holds() rethrows immediately (line 154) instead of treating it like every other refusal that may be a lagging node. steady() retries 5 times 1 s apart per chunk, so one chunk failing for 5 seconds is enough; for open weeks after deployment there are 20+ chunks per pass and 3 passes.

The error text tells the owner to count the logs on Etherscan and pass --logs-checked-on-etherscan, a flag that disables the extraTokens check entirely and that the tool cannot verify (README section 5). A transient fault therefore produces a false refusal whose suggested remedy removes the check, while the stable, intended case (an RPC whose range limit is below 10,000 blocks) is indistinguishable from it.

The fallback is sound in its invariant: it is used only when hashes is non-empty, so a transaction of the same step at the same nonce already exists and at most one of the two can land, and no step but the deploy can be sent on it. It is sufficient today (largest step 169,104 gas, so 5.9x headroom).

It is, however, an untethered constant: the preflight comment at line 333 already anticipates a repricing (~6.3M -> ~40M for the six transactions 'if EIP-8037 is live'), under which a storage-heavy step such as setRevealURIs could exceed 1,000,000 and the replacement would land out of gas with status 0, burning the whole limit and ending the run with TX_FAILED (the resume then counts the reverted nonce and resends, so the loss is one failed transaction).

The first send of every step always came from a successful estimate (hashes empty, no fallback), so that limit is known and is the natural value to reuse.

tokenLogs always starts its first chunk at the record's startBlock (line 97 / 107). The default RPC (PUBLIC_RPC, line 37) does not cap the width of a log range: it refuses any eth_getLogs whose fromBlock is more than about 10,000 blocks behind its head, with -32602 'Archive requests require a personal token'.

Chunking cannot help, because the very first chunk is the old one. steady() retries it 5 times, the .catch turns it into extraTokens=null, checkRecord throws LOGS_UNAVAILABLE, and holds() rethrows it at once (line 154). The owner's plan runs open days or weeks after the deploy: the metadata host, Worker and final list are not built yet, and USDC only becomes usable after two days.

So on the default RPC open cannot pass without --logs-checked-on-etherscan, and that flag skips the extraTokens check entirely. The check that the deployer key, which holds every owner power until the Safe accepts, added no second payment token is therefore skipped in the normal case. AUDIT_README section 5 says only an RPC 'whose log limit is under 10,000 blocks' hits this and that the default RPC 'was not tried'.

That is the wrong mechanism: the limit is on age, not range. status (line 199, holds(state,x=>x)) also prints extraTokens:null with no warning. The same RPC refuses eth_call pinned 127 or more blocks back. The current code re-reads the head before each pass, so it is not hit by that, but it rules out pinning reads to the record's block on this RPC.

Fix: Read the count without history. For example, read extraPaymentTokenCount with eth_getStorageAt at the pinned head, using its slot from the build's storage layout, and compare it to 1 in checkRecord, keeping the log count as an optional cross-check. Alternatively require a READ_RPC_URL that serves logs from the deploy block for accept/open.

Also have status warn when extraTokens is null, and correct AUDIT_README section 5.

A recorded step holds one hash, the one whose receipt firstReceipt saw first (line 197). The tool itself keeps up to 8 competing transactions of one step at one nonce (25% higher bids after stepTimeoutMs). Suppose h1 is mined and settled (3 reads about 6 s apart, inside one slot) and pushed into steps[], then a 1-block reorg drops its block and the next builder includes the step's replacement h2.

The chain state is right, but eth_getTransactionReceipt(h1) is null for good. Every later --resume runs settled(steps.at(-1)) first: it polls visibleTries (90 x 2 s) and throws RECEIPT_NOT_VISIBLE, before codeAbsent, the gates, NONCE_MOVED or the read-back. AUDIT_README section 5 says a reorg-removed recorded step leads to a read-back mismatch that a person checks.

On this path the read-back is never reached, and nothing says what to edit. deploy-mainnet.ps1 line 112 tells the owner to run RESUME again, which loops on the same stop. A step pushed from seed (line 158) becomes steps.at(-1) on the next resume and has the same exposure. This is a liveness fault only: nothing is sent.

(Merges the audit_math and audit_permissions findings.)

Fix: Record every hash of a step (hashes is known at line 197) and accept a receipt for any of them in settled. If none appears, drop that last entry from steps[] (or skip the wait) and let codeAbsent/notDone and the read-back decide from the chain. At minimum, name the manual edit in the error and in the README.

AUDIT_README 4.1 says 'A reverted waiting transaction is not pushed, and its nonce is counted'. That holds only on the seed path (line 157). In send(), a reverted receipt does nonce++ (line 192) and then either retries (revertRetries, line 194) or writes checkpoint(state()) with no pending and throws TX_FAILED (line 195).

Neither path leaves anything in the record about the spent nonce. On resume, floor=planNonce+steps.length is one below the chain, so the bound that answers audit 358f7f40 finding 1 is missing, and nonce comes only from stableNonce(): two reads that a lagging node can answer stale. Case 1, a reverted deploy: the owner should get PLANNED_NONCE_USED at once.

Instead the tool broadcasts a second deploy at the spent planNonce. A fresh node refuses it, so no second contract is created. The run then stops with NONCE_MOVED.

If the node is still behind, it can accept the transaction into its pool and the loop waits 8 x stepTimeoutMs. Case 2, a reverted setRevealCommit attempt followed by a retry that lands, then a kill before the next send: the resume sends addPaymentToken at the spent nonce and stops with NONCE_MOVED. The result is extra stops and time, with no loss.

(Merges the audit_math TX_FAILED finding and the audit_flow floor finding.)

Fix: Carry the run's next nonce in every checkpoint (state=>({...,nextNonce:nonce})) and set floor=Math.max(planNonce+steps.length, resume.nextNonce??0). Or record reverted attempts (status 0) in a failed[] list that the floor counts, which also makes totalGas include the burned gas.

The prologue gives the waiting transaction firstReceipt(seed.hashes,pollMs*5), about 10 s. If its nonce is not yet spent, seed stays and nonce=seed.nonce. The seed step's gate runs later, after codeAbsent, codeVisible and the RESUME_CODE/RESUME_NOT_OWNER reads.

If the transaction is mined in that window, notDone(seed.name) says done. Nothing then advances nonce, clears seed or records the receipt: nonce++ only happens inside send. The next step's send hits line 171 and throws RESUME_OUT_OF_ORDER, whose text points at an out-of-order record when the real event is that the waiting transaction landed.

A second resume finds the receipt and continues. The same mechanism makes the stop repeat under a lag pattern where receipt and nonce reads come from a node that is behind and the gate read from a fresh one. The cost is an extra run and a wrong diagnosis, with no loss.

(Merges the audit_math finding and the audit_economics info finding.)

Fix: In notDone, when the gate says done for seed.name while seed is set, wait for firstReceipt(seed.hashes), push it to steps if status 1, then set nonce=Math.max(nonce,seed.nonce+1) and seed=null. Include the seed hashes in the RESUME_OUT_OF_ORDER text.

last is set before sendTransaction, so any error raises the next fee: a gateway 502, SERVER_ERROR, a rate limit or INSUFFICIENT_FUNDS. When nothing is sent, the loop waits only pollMs*3 (line 190), so 8 attempts fit in well under a minute. There is no ceiling, and a resume restarts the chain of bumps from the recorded fee, so two stuck runs compound.

On mainnet the tip is paid in full, so an RPC fault alone, with no competing bid anywhere, overpays the 5.9M-gas deploy by about 7.5 gwei/gas, or ~0.044 ETH at a 2 gwei market tip. A timeout after broadcast does need an outbid. The defect is that the bump is not limited to errors that can mean a bid exists, and is not capped.

(Merges the audit_flow low and the audit_economics info findings.)

Fix: Bump only after a successful send, or on errors that can mean a bid is held: REPLACEMENT_UNDERPRICED, 'already known', or a timeout after broadcast. Add a ceiling on maxPriorityFeePerGas, for example 3x the first attempt, after which the run stops with STEP_STUCK.

chainState maps every tokenLogs error to extraTokens=null (line 107). That includes transient ones: a timeout, a 429 after the 20 parallel eth_call reads, or a node behind the pinned head refusing toBlock. One chunk failing for about 5 s (steady: 5 tries x 1 s) is enough. checkRecord then throws LOGS_UNAVAILABLE, and holds rethrows it at once.

A CHAIN_DIFFERS_FROM_RECORD or HEAD_BEHIND_RECORD from the same lag is retried for up to 10 passes. The resulting message recommends --logs-checked-on-etherscan, which turns the check off. This is separate from the structural refusal by the default RPC, which is reported as the medium finding.

(Merges the audit_flow and audit_economics findings.)

Fix: Treat LOGS_UNAVAILABLE as an ordinary refused pass, and throw it only if it is still present when tries run out. In tokenLogs, map only the RPC's explicit range/limit errors to null and let other errors propagate.

The fallback (line 179) runs only when the step already has a hash and is not the deploy. The replacement shares the nonce, so it cannot double-execute, and with fixed calldata it reverts only if the waiting transaction would also revert. Under today's pricing the limit is enough: the largest step is 169,104 gas, 5.9x headroom.

It is not tied to anything, though. Scaling the project's own preflight allowance (~6.3M to ~40M 'if EIP-8037 is live', 6.3x) to setRevealURIs gives ~1.07M, above the constant. A replacement mined on that limit would go out of gas, burn 1M gas and end the run with TX_FAILED.

That would also hit the uncounted-nonce finding above. The first send of every step used a successful estimate, so a known-good limit exists.

Fix: Keep the last successful limit for the step, and store it in the pending checkpoint as gasLimit so a resume can reuse it. Fall back to that, using REPLACEMENT_GAS only when no limit is known.