Why it does that.

Most collections are not verified when they start minting, so there is no published list of functions to read. The bot works from the contract's own compiled code instead, and there are only two places a public mint can live.

A candidate is only ever tried when its four-byte selector is physically present in the bytecode of whatever it is aimed at. Nothing is sent on a guess that the receiving contract has never heard of.

Which router, and whether there is one

The collection is asked first, because an OpenSea drop names its own routers. When it will not say, the bot falls back to SeaDrop's canonical address and reads the code there.

The price, and what counts as absurd

Where a router is in play, the price comes from the router's own sale record rather than from a getter on the collection. Either way the reading is checked against a ceiling, because a function named mintPrice on an unverified contract may return a timestamp, a supply, or nothing recognisable, and the only defence is that it is not a plausible amount of money.

Plausible depends on the token. Ten of a chain's gas token is a five-figure sum on Ethereum and ten dollars on a chain that prices gas in a stablecoin, so the ceiling is per chain:

Allowlist calls, one per wallet

The simulation finds a working call for one wallet, and an allowlist call carries that wallet's address and proof in its arguments. Copied to a second wallet, it reverts with certainty. So the simulation records the function it built as a signature, for example wlMint(uint256,bytes32[]), and every wallet's call is rebuilt from that signature by the same encoder, with its own address and its own proof.

The simulation and the open-watch both run as the first selected wallet that holds a proof, not the first one listed. A list that covers only some of the wallets therefore still simulates clean.

Before anything is signed, the final bytes of every wallet's call are checked for that wallet's proof, word for word. That check is on the bytes that will actually be sent, so it holds whatever path built them.

A wallet left out for any reason, this one or too little money, is not part of the race either, so it cannot hold the result open waiting for a transaction that was never sent.

Allowance lists

A list whose leaves are (address, amount) — “this wallet may mint 3” — is matched the same way, against both the packed and the OpenZeppelin double-hashed encodings, after the address-only shapes fail. A match returns each wallet's amount with its proof. The contract rebuilds the leaf from the arguments it is given, so the amount must also be in the call, in the argument it reads it from.

That argument is taken only from a verified contract's own ABI: a function with at least two uint256 inputs, exactly one of them named like an allowance (allow, max, limit, cap and similar). Unnamed arguments are never guessed, because a wrong slot is a revert. At Arm the server checks the final bytes of each call carry the wallet's own amount in exactly that slot; a wallet whose call does not is left out with ···4f2a left out · call would not carry its own proof.

Matching a large list

Leaves are hashed once per encoding and shared by every layout that uses it, the tree is built on raw bytes, and each proof is looked up by index. Trying every construction against a 50,000-address list that matches none of them took eleven seconds and now takes about five. A list already matched is cached on the server by chain, contract, root and the list's own digest, so pasting it again for another Arm costs nothing, and the proof route may run for up to a minute rather than being cut off by the platform's default.

Signed allowances

For a signature-gated sale the server asks the project's own endpoint once per selected wallet, checksummed address first, then lowercase, and takes the first 65-byte signature anywhere in the answer. An allowance is taken only from a numeric field named like one. Nothing else in the answer is used. The signature goes into the wallet's bytes argument; the simulation then runs as a signed wallet, and because the message a contract checks differs by project, the contract's own answer to that call is the only check that cannot be wrong. At Arm, a wallet with no signature is left out, and so is one whose call does not carry its own.

Lists the contract keeps itself

When the bytecode carries a membership getter such as isAllowlisted(address), the cockpit asks it about every selected wallet as soon as the simulation has found it. Any non-zero answer counts as on the list, because the same getter is as often an allowance (“may mint 2”) as a flag. A getter that reverts or returns nothing readable has not answered, and an unanswered wallet is never left out.

At Arm the server reads the list again itself; the browser only says which getter. A wallet is left out only on a clear no that its own call agrees with: if the getter says no but that wallet's call would pass, it races, because a getter can be named like a list and mean something else. Before the sale opens every call reverts, so there the getter's answer stands on its own. Only the getters the gate check looks for can be called; the list check is not a general call relay.

A sale opens when a block's timestamp crosses the start time. By the moment any watcher can observe that block, the block is built and sealed. Anything that waits to see the open has already missed the opening block, and no amount of connection quality changes that. It is true of a server beside the sequencer and it is true of a phone.

So the bot fires before the open, by roughly the time it takes a send to travel:

fire at:  opensAt − measured send latency

Which requires knowing what time it is on the chain, and your device does not. Clocks drift, and the drift is often larger than the margin that decides the race.

Block times

Measured, not quoted: the timestamp span of the last 2,000 blocks divided by 2,000. They set how often the open-watch and the clock read, how long a bid waits before it is outbid, and how the risk of landing a block early is shown.

The chain clock

Each block header carries the time it was produced. Sampling headers and keeping the maximum of timestamp − observedAt gives the chain's clock, because network delay only ever makes a sample look older than it is. Delay can only bias one way, so the extreme is the truth and the noise is everything else. A read that fails moves the clock to the chain's next endpoint, so one endpoint being down cannot leave the schedule without a clock.

What it aims at

The opening time is read when you arm and kept with the race. Looking at another contract while a ladder is held changes what the screen shows, never when the held ladder fires. It used to read the screen, so a glance at another contract could aim the held ladder at that contract's opening time.

The clearing price of a contested mint is not knowable in advance. Bid low and you are not included; bid the maximum every time and you overpay on every quiet mint. So the bot signs a ladder: the same purchase at several fee levels, all prepared before the sale opens.

Every rung is capped by what the wallet can actually afford and by the gas budget you set, so a ladder never signs a rung that would bounce. Those are caps, never targets: money sitting in a wallet is not a reason to bid more. Every rung keeps the room the starting bid had for the base fee to rise, and when the floor between rungs leaves no room for all 6, the ladder has fewer rungs with the top one still exactly on the budget.

Which rung is sent first

Rung 0's tip is the median of the last five blocks' tips at the setting's percentile, read with eth_feeHistory, so one empty or one spiked block cannot set it. That is what a quiet block cleared at, not what a contested opening block will. The rungs above it used to be reachable only by replacement, and a replacement cannot enter a block that has already been built. So on a chain that sells ordering, the opening bid is the only bid that competes for block one, and each setting now chooses it:

A setting never opens below the cheapest rung that clears the current base fee. On first-come chains every setting opens at rung 0, because the tip there is an admission fee rather than a bid. The box is handed the same opening bid, so it does not quietly open lower than the setting says.

Climbing

After the first send, every watch tick reads the base fee of the block being built and the 95th-percentile tip of the latest block, which is what it took to be in it. A wallet still pending climbs its own signed ladder for one of two reasons:

A climb sends a rung that was signed at Arm, straight from the browser and through the server at once, so it costs one round trip and no signature. It only ever goes up, and every rung is already capped by the gas budget and the wallet's balance, so no climb can spend more than was agreed at Arm. A send that never reached a node is retried with the identical bytes; one a node refused on price is not, because the same bytes get the same refusal. Where no ladder is held in the browser, as after the box fires, the old path remains: a fresh signature at a fee the server suggests, within the same budget.

Gas limits

Each transaction's gas limit is the simulation's estimate plus 50%, or plus 40,000 gas when that is more, for a wallet whose first mint writes storage the estimating wallet already had. A fixed floor is used only when there is no estimate, as before a sale opens.

The limit is not free even though you are billed only for the gas you use. The gas budget becomes a per-gas cap by dividing by it, so an oversized limit lowers every bid the budget allows, including the one Nuke opens at. And on a chain with small blocks, a limit that is too high is a transaction that does not fit.

Two other answers look like it and mean something else. “Nonce too low” means the nonce is already spent — often by this very transaction, when the browser's copy was mined before the server's arrived — so the transaction's own hash is kept and its receipt decides. “Replacement transaction underpriced” means the node holds a different transaction for the nonce and refused this one; it is recorded as refused. Both used to be counted as sent.

Keeping track after the send

From the box

The box reads and sends differently, because the two jobs want different things. A read wants one good answer. A send wants the transaction in as many mempools as possible, as early as possible.

A send that never reached a node is none of these. It is a transport failure and the wallet is still live, so it is retried rather than recorded as a loss.

The receipt also says which block the transaction landed in, and that block's own timestamp is read once. How long after the open a mint landed is measured from it — the chain's clock — rather than from when the screen happened to poll, which on a half-second chain was two to four blocks of error in the one number that says whether you made the opening block.

The receipt is also read for the token ids, since every mint emits a transfer from the zero address. ERC-721 is told from ERC-20 by topic count: an indexed token id makes four topics where a fungible transfer has three.

Solana has no per-wallet nonce to make a fee ladder safe, no mempool to watch, and a recent blockhash that expires in about a minute, so a bid signed at Arm would be dead long before a scheduled open. The Ethereum engine's machinery does not transfer; its shape does. Solana gets its own engine with the same flow — prepare, sign on the device, hold, send everywhere, watch, outcome — and shares the keystore, the licence, the stage words and the screen.

One hold per wallet, so at most one bid lands

Each wallet gets a durable nonce account — the hold — at an address derived from the wallet and the seed easternbot-hold-v1, so nothing extra is stored and it can be found again from the wallet alone. It costs 0.0011 SOL of rent, refundable. Every bid and the cancel for that wallet are signed against the hold's current value instead of a blockhash, and each starts by advancing it. The first to reach a block moves the value; every other one is then rejected before execution, which means it is never charged. That is the Solana equivalent of every Ethereum rung sharing one nonce, and it is what makes a pre-signed ladder safe.

Every transaction has the same shape

advance hold → compute limit → priority fee → [tip to Jito] → mint × quantity

The mint is last because a guard with bot tax can be set to charge any mint that is not the final instruction. The mint instructions come from Metaplex's own clients (Core candy machine mint_v1, Candy Machine v3 mint_v2), with the guard arguments filled from the guard's on-chain settings: a payment can only go where the creator set it to. When a transaction does not fit Solana's 1232-byte limit — a programmable NFT with several guards comes close — the tip is dropped first, then the compute limit instruction; beyond that it is refused.

What the device checks before it signs

The server builds; the device holding the keys decodes every message and refuses anything outside this list:

Setup, cancel and deposit returns have their own, shorter lists. The server applies the same shapes before relaying anything, and checks every signature, so it is not a relay for arbitrary transactions.

When it fires

Holding, the device simulates the signed opening bid itself every 400 ms — signature checks off, against the processed bank — and asks the simulation to report the NFT account the mint would create. It fires on the first simulation that passes and creates that account. The second condition is the bot-tax check: a taxed mint succeeds as a transaction but creates nothing. Before 3 seconds to the open by the chain's clock, it only counts down. The browser simulates against a public endpoint; if that does not answer, the server simulates instead.

Firing on a passing simulation costs about one slot against firing blind at the open. It is the only honest choice here: an early bid either fails and spends the hold — so the ladder is gone — or, on a taxed machine, pays the tax.

Getting it there

Reading the result

One call every 800 ms asks for every signature sent so far (getSignatureStatuses), every hold's value, and the machine's count. A bid found in a block settles its wallet: in if it succeeded, failed if not — then the landed transaction's logs are read once so the screen can name the rule that refused it. Confirmed means the network's supermajority voted on that block. A hold that moved with none of our signatures found is given 8 s for statuses to catch up, then called missed. Sold out with every hold unmoved means nothing of ours landed and nothing was charged, so those wallets end there.

Compute units come from simulating the mint at Arm when it is open, padded by 25% plus 10,000; otherwise 200,000 for Core, 350,000 for v3 and 450,000 for programmable NFTs.

Everything else the bot signs is a transaction: it fails loudly, costs gas, and leaves a receipt. A listing does none of that. It never reaches a mempool, costs nothing to make, does not expire until it says it does, and hands whoever holds it the right to take the token. At signing time, a listing that sells a token and one that gives it away are the same shape.

So the signer does not sign typed data. It signs listings it has read, and refuses anything it cannot state in one sentence:

Checked by the contract, not by us

Before a listing is offered to anyone, the marketplace contract is asked whether the signature is good. Its validation entry point is a transaction, but called read-only from an address that is not the seller it runs the real signature check and answers for nothing. The contract that would settle the sale is a better judge of the signature than the code that made it.

The settlement contract sits at one address on all eleven chains the bot mints on, so the order is the artifact and the marketplace is only an orderbook. A failed post loses nothing: the signed order is still there to post anywhere.