How a round works

A round is fifteen minutes apart from the last one. Every round follows the same sequence, and the sequence is the same for all four models.

1. One market snapshot

Before any model is called, the runner takes one snapshot of the market: the tokens it is tracking, their prices, liquidity, volumes, transaction counts and holder counts, who controls each pool's liquidity and the deployer's share and record, for a PONS token its stage (curve or graduated) with its curve's own flow and fill or its graduation price and low since, each token's timing (minutes and multiple since launch, the high since and how far under it the price is), its largest 15-minute fall in the last hour, plus the block number it was taken at. Inspecting a token adds a rug-risk block in plain words and a buy-then-sell simulation from the model's own wallet. All four models read that same snapshot for the whole round, so none of them can see a price the others could not.

A round is badged degraded when its snapshot was thinner than half the previous snapshot, or a token in it missing data that no source could supply. A source that failed while another one covered for it does not degrade a round: nothing a model read was worse for it. The models trade on a degraded snapshot anyway, and the badge says so.

2. Four turns, in parallel

Each model gets its own turn, with the same system prompt, the same tool definitions and the same budget: 10 tool calls, including buy, sell and hold; up to 3 trades a turn; one extra decision-only call if the turn ends without one. The turn has 150 seconds of wall clock. Every tool result tells the model how many calls it has left.

A turn ends when the model holds, stops calling tools, or uses its budget; a buy or a sell does not end it. If it ends without the model having bought, sold or held, the model gets one final call in which only buy, sell and hold are available; the round is then labelled forced decision, with the reason. A hold is always the model's own call — a turn a model did not play is shown as skipped, never as a hold.

A turn that fails with no trade is retried once after 20 s, within the same 150-second window and the same 10-call budget. The calls and the seconds the failed attempt used count against the retry. A turn that fails again is shown as skipped (error).

A turn's reasoning is what its decision call carried: the reasoning field of its buy or sell, or the reason of its hold, written with the whole turn in context. If a turn ends with no decision call at all, or its reasoning only restates the trade, the model is asked once, with no tool available, to explain the decision it just made. That row is badged reasoning: follow-up.

3. The decision is logged before it is executed

The decision row — reasoning so far, every tool call with its result, the guardrail verdict — is written to the database before any transaction is signed or sent. If the process dies mid-round, the restart settles what was already logged instead of sending it again.

4. A trade is checked, simulated, then sent

A buy runs in this order, and stops at the first refusal:

1. Guardrails: the kill switch; an unsettled transaction from the wallet; membership of the round's snapshot; the size limits (at most $30 a trade and 10% of the wallet's cash, or 3% of cash for a token whose pool liquidity its owner can withdraw or whose control is not established yet, and at least $2: below about $67 of cash that 3% is under $2, so such a token cannot be bought at all); the round's 3 trades; the liquidity floor; the liquidity rule's refusals (a lock ending within 7 days, a launchpad whose contracts changed since they were verified); an upgradeable proxy; the token's age; its market cap; the position count; the gas reserve.
2. A buy-then-sell simulation from the wallet as the plain account it is, at the block's real base fee: the buy in one block, then an approval and the sale of the wallet's whole resulting balance in a block 60 seconds later. The token's transfer code runs on both legs, and this buy's share of what the sale returns must be at least 70% of the money. For a PONS bonding curve or a graduated v4 pool the same gate runs the trade's own steps from the wallet and then the sale. A token that cannot be sold is never bought.
3. A quote, then a simulation of the exact trade, then the broadcast: one transaction on a Uniswap pool. On a PONS bonding curve paid in ETH a buy is two transactions (USDG to ETH through the Universal Router, then the curve's buy with exactly the ETH the first step produced) and a sale three (an approval, the curve's sell for ETH, ETH to USDG through the router); a graduated v4 pool is one transaction each way. Each swap leg carries its own minimum at the trade's slippage cap, so a curve sale's two priced legs can together give up about twice it (about 6% at 3%). Before the buy is sent, the price its fresh quote implies is compared with the price the round's snapshot showed: more than 10% above it, or above the limit the model set on the buy (maxPriceRisePct, up to 100%), and the buy is refused with nothing sent.
4. Confirmation, then the trade, the position and the new equity are recorded. buy and sell wait up to 90 seconds; a trade whose transaction is sent but not yet confirmed answers "sent, pending", the runner settles the whole operation, and the next turn message says what it did, from its final settlement. An exit plan the buy carried attaches then, judged against the fill. A trade of several transactions is settled as one operation: a step that failed after the first leg leaves ETH in the wallet, which counts in equity and is converted back to USDG at the failure and at every round's start.

Sells skip the liquidity, age, market-cap and position checks: a model can always reduce or close a position.

5. Between rounds

The market poller keeps running the whole time, about every 85 seconds. When a pool launched in the last hour crosses the liquidity floor, it asks for an extra round; the round runs only for a launch that is still on the lists when it is due, is at least ten minutes old, and still passes the entry bar the prompt states (twenty buys in five minutes and $30k in the pool, or ten distinct buyers in the hour on a curve). A younger launch is waited for and judged again; a crossing that fell back under the floor, or that nobody is buying, wakes nobody, and the skip goes on the record. In live test 6 the extra rounds put every model in front of launches minutes old at their spike. A PONS token seen graduating asks for one too, judged from its graduation: still listable, at least ten minutes since it, and twenty buys in five minutes (a pool a curve seeds holds less than the $30k bar). A position that has moved also asks for one: when any model's holding is up 80% on its price at the last round, or down 35% from its highest price since that round, the poller asks for an extra round (the "position wake"), and the message that opens every model's turn says why the round is running. These extra rounds are capped: at most two an hour after launches and two an hour after position moves, each on its own budget, at least five minutes from any other extra round, and never within three minutes of a scheduled round, so a busy launch hour cannot crowd out the fifteen-minute rhythm, and a position that collapses is not made to wait for the launches' budget. Every model plays an extra round exactly as it plays a scheduled one.

After a restart the poller does not crawl the whole gap: it reads the newest ten thousand blocks of pool creations and, for the blocks it skipped, the launchpads' own launch events (about a day back), so a launch that never traded is still in the table. Every token a snapshot can hold is checked for who controls its liquidity and asked of the launchpads, not only the most visible fifty.

PONS v2 launches (about ten thousand a day) are read from the factory's own launch events. Every launch becomes a candidate in memory; the youngest 150 curves are read each poll, and a token enters the table only when its curve shows a market (real ETH in it at 1% of the graduation threshold, or 0.2% of it gained between two reads), at most 20 a poll; a candidate that shows none for six hours is forgotten. A curve's price and depth are read from the chain every poll, and its own trades are its flow and its candles.

From on-chain prices, as each trade in the token's pool happens, with a check every 30 seconds as a fallback, the runner also checks each position's standing orders, the exit plan a model attached with buy or set_orders: take-profit levels, a stop-loss, a trailing stop, and a secure-initial level that sells just the share returning the model's stake at its multiple. An order that triggers is logged first, then sold through the same executor as a turn's sell, under the same sell guardrails, the same slippage cap and the same reverted-sell policy. The sale appears on the live feed as that model's standing order, with the round the order was set in, and the model is told at its next turn. No order exists unless the model set it. An order's sale is not one of the model's 3 trades; a position sells at most 2 orders a round, and a level past that waits for the next round. A level being sold is marked so it cannot trigger twice, and a plan the model replaces during a sale is kept whole.

The runner also checks each model's entry orders in the same check: a buy the model placed to fill when the price falls to a level, at most 3 open, one per token, each for up to 240 minutes. One whose token trades at or under its level is bought under every buy guardrail at that moment, with the price-rise limit measured from the level; the fill is not one of the model's 3 trades, and an order not filled in time expires. The next turn message says what became of each.

The check reads the price of every token with an open order on chain, all in one call, and nothing at all while no order is open. A token whose read fails is judged on the last poll's price. These prices are only for the orders: the market data the models read each round is still the poll's.