Wallet screening

Wallet screening, its auto runs, the hourly check of which racing wallets miss the block and the pool itself now live on one page.
Open Admin → Wallets → Screening

Rivals

Network relayers that raced us in the last 7 days, grouped by how they bid on contested documents: a fixed tip shared by several wallets (usually one operator), or a tip that follows the market, split by whether it equals the max fee. Name a group after its operator and give it a colour: admins then see its members marked on the Relayers leaderboard. A relayer you move to another group stays there; the rest are re-classified every 6 hours from the Block timing recorder's mempool log.

Strategy groups

New group

Public: visitors of the Relayers leaderboard see the group's members marked under its public name only — never the internal name or the strategy. A group needs a public name before it can be shown.

Our fleet on the public leaderboard

as

Rival phases

A relayer sees a new document only when its own 60 s CargoX cache flips, and sends the relay TX ~100–200 ms later — so every relay TX in the live mempool feed shows when its sender's cache flips. From that: who flips when in the minute, who is due in the next seconds (and so may still come for a document we see now), how they bid, and whether the prediction holds. Only the live (real-time) feed is used; batched Alchemy hours arrive in 1 s ticks and are ignored. Read-only — nothing here changes bidding.

The minute right now

Rival slot (racing, stable phase) — colour = rival groupOur racing relayer (true cache phase)Window a rival flipping now could still beat us (−0.5 … +2.5 s)Now

Who flips next — the next 15 s

countdown to the predicted send · ± = the slot's median miss

Does the model hold?

every new flip of a sender that was stable just before is scored against the prediction
Miss of the prediction, racing rivals (since the tracker started)
Check on our own relayers: the phase the model reads from our TXs vs the true cache phase (the gap is our send lag + feed lag)

Replay: would the prediction have been right?

Our contested sends in stored live-feed hours, replayed in time order with only what was known at that moment. A send where a rival was already pending is left out (the mempool shows it anyway). For the rest: who was predicted to come, and who did come within 3 s. "Empty window" = no stable racer due, no racer without a phase active in the last 10 min and no active mempool copier. What-if = the first bid at factor × today's bid on empty-window sends; reward at risk is pessimistic (no rebid rescue).

Pick a period — the replay runs on the server (a few seconds for 7 days).

Where our phases could stand

Share of documents released at a random moment that one of our racing relayers sees before every stable racing rival (the first cache flip after the release sees it first). Rival flips = their send phase minus the send lag measured on our relayers. Racers without a stable phase are not in it. Display only — nothing is moved.

All tracked senders

Queue snapshot

Who receives the next new documents as reserved — every relayer active today ordered by its CargoX queue position — and how it bids in contested races (its winning bids in the last 7 days, from the market scan). One low-priority call per relayer, ~3 per second, so the racing relayers keep their slots. Runs only when you click; the queue moves with every document, so a snapshot is good for a few minutes.
Queue #RelayerDocs today Contested wins 7 d Median bidMax bid
No snapshot yet — click Load queue.

Block timing

Polygon's block rhythm as our server sees it, and whether a rival relay TX shows up early enough to answer it with a higher bid before the next block. A recorder on its own WSS — never a racing relayer's — logs when each block reaches us and every pending relay TX. Alchemy delivers the mempool in ~1 s batches; another WSS that streams full pending TX bodies (newPendingTransactions, e.g. Chainstack) delivers it in real time, but streams the whole network's pending flow (~130 KB/s) — use a key no racing relayer depends on, and take Blocks from a fast endpoint. A same-nonce replacement must be sent a little before a block reaches us to still make it — and the higher the price, the later it may go: about 1 s at 30 gwei, ~450 ms at 100 gwei, ~300 ms at 500 gwei (Replacement test below). The rebid uses the live cut-off setting.

Recorder

Mempool plan

weekly slots, UTC
Each slot picks the mempool source and the Mempool assist features it allows. Live = a key pool with a real-time feed (full-body newPendingTransactions, e.g. Chainstack). P2P listener = our own devp2p listener alone: real time, no billed key, blocks from the Blocks endpoint. If the listener is down for 30 s, the next live key of the pool stands in (billed) until the listener has been back for 2 min. Batched = the Alchemy key pool, delivered in ~1 s batches — rivals show up to a second late, so it allows only Raise and Rebid. A feature works only when the relayer has it ticked and the slot allows it. Outside every slot the recorder is closed and relayers bid plain Dynamic Boost.
livebatchedP2P listeneroff / no slotclick an hour to select its slot

Key pools

P2P listener slots take the mempool from our devp2p listener alone (switch on the P2P mempool source; blocks come from the Blocks endpoint, no billed key). Flag WSS keys Mempool pool under Admin → RPC: Alchemy keys join the batched pool, any other WSS (full TX bodies) the live pool. A slot set to Any takes the key used longest ago, so the keys wear evenly; a slot can also pin one key. A key that fails, refuses the subscription, sends bare hashes or reaches its budget hands over to the next, and a live pool with nothing left falls back to batched for the rest of the slot. Edit a key to give it its own budget, the start of its 30-day billing cycle and the messages already used this cycle (e.g. from the provider dashboard — Chainstack bills every subscription event).
saved with the plan
Live settingsUsed by relayers
Applies to relayers with Rebid (and optionally Start low) ticked in their settings, only while the recorder is live. The rebid only raises against a visible rival, so it needs just the time to send a replacement; the low start risks a late rival, so it needs more. With less time left they race standard Dynamic Boost.
Shark — relayers with Shark ticked (with Raise) wait with a cold CargoX cache and hunt a document when a rival's relay TX shows up in the live mempool. Saved with the button above.