Internals · SolidFlow docs

How it is built

Four parts, and the only one that ever holds a key is the one you run.

The cockpit

Browser

The page you operate. It reads contracts, simulates, builds transactions and shows state. It never holds a key and never sees a seed phrase.

The signer

Yours

Holds the keys and signs. Either the encrypted keystore in your own browser, or a process on a machine you control. It receives unsigned transactions and returns signed ones.

The box

Optional

A server that watches chains over persistent connections and fires pre-signed transactions from beside the network rather than from a phone.

The scout

Scheduled

A separate process that finds collections the moment they start minting, scores them, and posts the result. It cannot arm anything.

Firing on time

Reacting to the opening block is already too late. So it does not react.

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.

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.

The fee ladder

Several rungs of the same purchase, signed before the open, at rising prices.

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.

	Value	Why
Rungs	6	Enough resolution to find a price without spraying.
Span	12×	Top rung is twelve times the base. A contested mint can clear far above the quiet price.
Floor between rungs	10%	The network's own minimum for replacing a pending transaction. A smaller step is simply rejected.
On order-of-arrival chains	4 rungs, no span	Paying more does not move you up a queue that is not sorted by price.

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.

Getting it there

Connections are opened and warmed before the moment, not during it.

Warm first. Endpoints are contacted ahead of the open so the connection, the name lookup and the handshake are already paid for. A cold connection at the moment of firing costs more than everything else combined.
Send to all of them, take the first answer. Endpoints are raced rather than tried in order. One slow node is a node that loses nothing.
Sign early, send late. Everything that can be computed before the open is, so the moment itself contains a single network call and no work.
On Ethereum, a private path is available. It goes to a builder rather than the public mempool, with public sending as the fallback when it is not configured.

Reading the result

Three outcomes, and the difference between them is money.

Outcome	Means	Distinguished by
in	The purchase landed and tokens moved.	A receipt with a success status, plus transfer logs out of the zero address.
reverted	The chain ran it and rejected it. Gas is spent.	A receipt with a failure status. The revert reason is decoded where the contract gives one.
missed	It never landed: sold out, or beaten.	No receipt within the window.

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 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.

How mints are found

One log query per chain, on the event every mint emits.

A mint is a transfer out of the zero address. Watching that across a block range finds every collection that starts minting on a chain, including the ones nobody announced, for one query per window rather than a block scan.

Three event shapes are watched, and the position of the sender differs between them, which is the detail that matters:

Event	Standard	Sender is
Transfer	ERC-721	topic 1
TransferSingle	ERC-1155	topic 2
TransferBatch	ERC-1155	topic 2

The funnel

Discovery is cheap and enrichment is not. One twenty-seven minute window on Base turns up several hundred contracts that emitted a mint, and a run can afford to look closely at a few dozen. So what gets looked at first decides what the system is worth.

Candidates are ranked by distinct wallets that received one, then distinct transactions, then raw volume. Both of the first two are free, already in the logs, and they are what separates a sale from a batch transfer. Raw log volume ranks one wallet minting five hundred tokens to itself above fifty people buying one each.

How they are scored

A rules engine that shows its working, not a model.

Every score arrives with the list of what contributed and by how much, and the scorer is versioned so old rows keep the version that produced them. A replay compares like with like instead of rewriting the past.

Feature	Weight	What it asks
buyers	25	How many distinct wallets received one.
buyer_rate	20	How fast they arrived, per minute of chain time.
deployer_track_record	30	Has this deployer shipped winners before, by our own graded outcomes.
independent_txs	12	How many separate transactions carried the mints.
headroom	10	How much of the supply is left to mint.
is_collection	8	Does it claim a token interface at all.
named	5	Does it have a name.

At or above 45 a row is actionable and can alert. At or above 20 it is worth watching. Below that it is kept with the reason it was dropped, because an audit of what was thrown away is the only thing that makes “miss nothing” a claim rather than a slogan.

How selling works

A listing is a signature, which makes it the most dangerous thing here.

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:

the offerer is the wallet being asked, not whoever the request names
the offer is tokens, never money, and never a set matched by criteria
payment is in one currency, and at least half of it comes back to the seller
fixed amounts only, no price that moves over time
it expires, within thirty days

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.

Key handling

Where the boundary is, and what crosses it.

Crosses the boundary	Never crosses it
Wallet addresses and labels	Seed phrases
Unsigned transactions	Private keys
Signed transactions, ready to send	Passphrases
Transaction hashes and outcomes	Biometric data

Keys held in the browser are encrypted with a key derived from your passphrase, and the derivation is deliberately slow so a stolen file is not a stolen wallet.
Face ID and fingerprint unlock wrap the same encrypted material using your device's secure hardware. The biometric never leaves the device and is never sent anywhere.
The self-hosted signer exposes signing behind a token, on an address you choose. In the box configuration it is not published to the internet at all: the runner reaches it over an internal network, and nothing outside can.

What it cannot do

The honest list. Every one of these is a real limit, not a roadmap entry.

It cannot beat a block that is already sealed. Predictive firing is the answer to that, and it depends on the start time being readable from the contract. Where it is not, the bot cannot aim.
It cannot mint a signature-gated sale. Where the project's own server signs each buyer's permission, there is nothing to compute.
It cannot tell you what is worth buying. The board scores liveness and lineage, not taste. Its weights are unfitted priors and it says so.
It cannot see a chain nobody will serve it. Some public endpoints answer every other request and refuse log queries. When that happens the scout says the chain is unwatched rather than reporting a quiet day.
It cannot recover your passphrase. Nobody can. That is the point of it.