How the machine works

$AMM is run by one process holding one key. Every sixty seconds it executes the same five steps, and each step is a signed transaction from the wallet the coin was launched from, which pump.fun recorded as its coin_creator and which owns every position the agent has ever opened.

claim    creator fees from the pump.fun vault      -> capital
harvest  swap fees from every open position       -> income
buyback  100% of income, swapped to $AMM          <- income
deploy   whatever capital is left, into one pool  <- capital
record   cycle + position rows, for this API

The ordering is the argument, not a convenience. Buybacks run before deployment, so the balance left in the wallet afterwards is capital by construction. There is no moment in the cycle where income and capital are the same pile of SOL waiting to be split by a ratio someone chose.

Nobody maintains a pool list. Each cycle the agent rebuilds one. Birdeye supplies two mint lists rather than one: what is trending, which skews to new tokens with sharp turnover and short lives, and what is doing the most 24h volume, which surfaces the established pairs that quietly do size all day. A book built from either alone is lopsided. DexScreener then says which Meteora DLMM pools those mints actually trade in and how much depth sits behind that volume. Three sweep queries catch the rest.

Everything then has to survive four filters:

What survives is scored on one number: 24h volume divided by pool liquidity. Call it turnover. Fees are a share of volume and are split across the depth in range, so volume-per-dollar-of-depth is the closest honest proxy for what a position would earn that can be computed from public data alone.

The shortlist is cached in Redis for five minutes and read by both the agent and this site, so what you see on /pools is the exact candidate set the next cycle draws from, not a reconstruction of it.

The pick is weighted random over the top twenty, not the argmax. Always taking the leader would put the whole book in one market and chase whatever spiked in the last hour; weighting by turnover keeps the choice informed without making it deterministic.

shortlist = candidates.slice(0, 20)
ticket    = random() * sum(shortlist.turnover)
pick      = first candidate where running total >= ticket

Before that, the agent decides whether it is opening or compounding. Below six open positions it leans towards opening (35% of cycles, and always when it holds nothing at all); at the limit every cycle compounds into a pool it already holds. Opening a position it cannot afford to keep harvesting is how a book turns into a pile of rent.

Liquidity is deposited as SOL only. That is not a style preference. The agent's income is SOL, so depositing a pair would mean buying the other token first, which is a price view on every token it touches, taken automatically, sixty times an hour.

A one-sided deposit can only occupy bins on the side of the active price that the asset can be sold into. If SOL is the pool's quote token, the position sits at and below the active bin; if SOL is the base token, at and above it. Placing it on the wrong side is not a worse position, it is a rejected instruction.

As price walks into the range, the pool sells the agent's SOL for the paired token bin by bin. That is ordinary LP behaviour and the reason a position can come back as a mix of both assets rather than the SOL that went in.

A DLMM pool is a row of discrete price bins. Each bin holds liquidity at one price, trades inside a bin have zero slippage, and exactly one bin is active at any moment. A position is a contiguous range of them.

Compounding into an existing position reuses its original range rather than re-centring on the current active bin. Re-centring every minute would mean tearing the position down and rebuilding it, paying rent and fees each time, to chase a price that moves again before the next cycle.

Everything the machine claims rests on one distinction: money the coin generated (capital) versus money the liquidity earned (income). Capital becomes positions. Income buys the coin. Neither ever does the other job.

This is only checkable because of a specific property of DLMM: swap fees accrue outside the position rather than compounding into it. So the fees a position has earned are a number that can be read to the lamport and claimed on its own.

The second half of the guarantee is procedural. Harvest amounts are read off the positions before the claim transaction, never diffed from the wallet balance afterwards. The wallet holds SOL for three reasons at once, and a balance diff cannot tell them apart, which would quietly let deployment capital be spent as though it were income.

Every cycle sweeps every pool the agent holds a position in, whatever discovery says about those pools today. Liquidity nobody claims from earns nothing on paper and still pays its rent.

positions = getPositionsByUserAndLbPair(wallet)
claimable = positions where feeX > 0 or feeY > 0
amounts   = sum(feeXExcludeTransferFee), sum(feeYExcludeTransferFee)   // read first
txs       = claimAllSwapFee(wallet, claimable)                          // then claim

Fees come back in the pool's own two tokens, so a harvest is a set of legs rather than one number. The SOL leg is what the ledger reports as totalHarvestedLamports; other legs are recorded per cycle in harvestLegs and swapped in the buyback step.

A pool that fails to answer costs only itself. The loop catches per pool, so an RPC error on one market does not cost the others their cycle.

Each harvested leg is swapped to $AMM through Jupiter, which routes across every venue on Solana at once. The agent never picks a market; it asks for the best execution available that second.

A leg below the buyback floor is not dropped, it waits. The floor is checked against the wallet balance rather than the cycle's own amount, so dust accumulates across cycles and goes out with a later harvest of the same mint instead of being stranded.

Bought $AMM stays in the wallet. Nothing is burned and nothing is redistributed; the supply is simply held off the market by the address that bought it, and every buy is on chain under one auditable key.

Defaults below. All lamport figures; 1 SOL = 1,000,000,000 lamports.

The interesting part of an autonomous agent is what it does when something is wrong. It never guesses, and it never spends to find out.

No key, no rate limit beyond a ten-second edge cache, CORS open to any origin. Every response is { data, meta }; errors replace data with error and keep the same envelope, so a client parses one shape. All amounts are lamports as decimal strings, never numbers: a lamport total does not survive a double.

curl https://amm-bot.org/api/v1/state | jq '.data.ledger'

Ledger, the cumulative state.

Position.

Cycle.

Pool candidate.