Indexer, API and bots

Three processes sit between the chain and the page: an indexer that folds Uniswap and Kerf logs into tables, an API that turns those tables, the chain and three market-data feeds into the eleven routes the web reads, and three bots inside that API process that harvest, hedge and graduate. None of them holds a user's funds and none of them can move one: the web writes to the contracts directly, the API's only writes are a signed thesis, a signed perp envelope and a feedback form, and the bots spend their own key's gas for a bounty the contracts pay in the open.

The indexer

apps/indexer is a Ponder 0.16 app. It reads every log it is subscribed to, runs one handler per event, writes Postgres (or the bundled PGlite under .ponder/ when DATABASE_URL is empty) and serves the result as GraphQL on :42070. The API is the only consumer - every document it sends lives in apps/api/src/indexer/queries.ts - and the web never queries the indexer, so its schema can change without a browser noticing.

Sources and start blocks

There are two families of source, and they start at different blocks for different reasons.

The Uniswap sources default to deployBlock − 200 000 (POOLS_BACKFILL_BLOCKS, about thirty days on Robinhood Chain) when PONDER_POOLS_START_BLOCK is unset, because indexing v3 from genesis takes hours; production always sets it explicitly. The Kerf sources start at the manifest's deployBlock because nothing of theirs exists before it. With no PONDER_MANIFEST at all they fall back to the zero address and an endBlock of 0, so they can never fetch a log - they are still declared, which keeps the "Source:Event" types stable whether or not a manifest is present.

KerfVault is deliberately one source rather than three: LPVault, HedgedLPVault and StructuredVault share the handlers and a vault simply never emits the events its kind does not have. Three sources over the same factory parameter would index every vault three times.

The public RPC returns 429 above roughly 15 requests a second, so the transport is wrapped in Ponder's rateLimit at PONDER_RPC_MAX_RPS (default 15); 0 disables the throttle for a local node.

Which event feeds which table

Handlers are thin; anything with an edge case is a pure function in src/logic/ with tests in test/. Tests must not live next to the modules they cover, because Ponder executes every src/**/*.ts except src/api/** as an indexing file.

Three conventions the API relies on: every address and hash is stored lowercase (norm(), because viem checksums decoded address arguments but leaves log.address lowercase and the two must join); token amounts, liquidity and timestamps are bigint and cross GraphQL as strings; USD figures and percentages are real and whole percents, for display and ranking only, never a transaction argument.

Derived fields

Some columns are computed rather than copied, and each has a rule worth knowing.

Prices. priceCache holds USDG at $1 by definition (never stored), WETH from the latest WETH/USDG swap under the literal id 'WETH', and every other token as pool price × the quote's USD price, written on every swap in a pool whose other side is USDG or WETH. Volume is measured on the quote side of the pool, never on the risk asset, so a manipulated pool price cannot inflate it. A pool with no quote side contributes zero USD of volume. Only the canonical tokens have known decimals; anything else is assumed to be 18-decimal, which is why tvlUsd is a display field.

Pool TVL. There is no cheap honest answer, so the indexer uses two methods and says which. While a pool has at most TVL_EXACT_POSITION_LIMIT (200) open positions, tvlUsd is the exact sum of those positions' current value. Above that it values the active liquidity as if it were one position spanning TVL_APPROX_WINDOW_TICKS (953, about ±10 %) around the current tick, which understates a pool spread wider and overstates one tighter. TVL is recomputed on Mint/Burn and on the first swap of each hour, not on every swap, because a full position scan per swap buys no better answer. v4 pools always use the approximation because their positions are not tracked.

24 h stats, APR and Established. poolHourStat is an hourly rollup; the trailing window is a sum over the last 24 buckets, refreshed when a swap crosses an hour boundary. apr24hPct is @kerf/core's feeAprFromPool over that window, and established is isEstablished: age ≥ 3 days, market cap above $1M and ≥ 100 trades in 24 h. A token with no supply source has marketCapUsd null and is never Established.

Range uptime. A v3 position earns only while the tick is inside the half-open [tickLower, tickUpper). Uptime is accrued on every pool swap for the interval since the last accrual, credited when the tick the pool held entering the interval was in range - the previous tick, not the new one, because the position earned at the old price and only moves to the new one at the interval's end. The clock never moves backwards, so a reorg cannot subtract uptime. rangeUptime mirrors position.inRangeSeconds as its own row so /portfolio can read it without loading whole positions.

IL vs HODL. ilVsHodlPct compares the entry amounts at entryPrice (the token1-per-token0 ratio at the first IncreaseLiquidity) with the live position plus everything already withdrawn. Collected fees are excluded on purpose: IL measures the principal, and fees are the compensation for it.

Five things that look like bugs

• A rebalance changes an enrollment's primary key. PositionKeeper.Rebalanced mints a new NFT; moveEnrollment retires the old keeperEnrollment row with succeededBy and opens a new one under the new token id with succeeds pointing back and the lifetime counters carried forward.
• Liquidated fires before Closed in the same transaction, so the Closed handler must not stamp closed over a row already flagged liquidated (perpStatusAfterClose).
• vault.paused is the flag, not the whole answer. It mirrors the contract's _hedgePaused, which HedgePaused/HedgeResumed report. HedgedLPVault.paused() also returns true when the last report has gone stale, and staleness needs no transaction and so emits no log; compare hedgeAsOf against the vault's maxHedgeAge or call the vault.
• Share transfers are not indexed. vaultShare.shares is clamped at zero; a holder who was sent shares has no record of them arriving. The API values a holding as shares / totalShares, so a transferred share is mis-attributed, never double-counted.
• referral.earned values are decimal strings, because JSON has no bigint and these are raw token amounts that routinely exceed 2^53. Taken with a zero referrer is skipped (there is no row to credit) and Claimed is not indexed at all (it moves an earned balance, it does not change how much was earned).

The three fork limits

Anyone who runs the indexer against an anvil fork of Robinhood Chain meets three properties of forking a live chain that look exactly like bugs.

1. PONDER_POOLS_START_BLOCK must be at or above the fork block. The public RPC keeps no archive state - it answers metadata is not found for a state read more than a few hundred blocks old - and the handlers eth_call positions() and orders() at each event's block. The documented default of deployBlock − 200 000 produces a wall of failed calls and a 22-hour backfill estimate; the smoke script pins the start block to the manifest's deployBlock.
2. An idle fork goes read-only. anvil fetches storage lazily at the fork block, and once the upstream has pruned it every slot the fork has not already cached is unreachable - measured at about 40 minutes. Deploy and write immediately after starting anvil.
3. The indexer can never see a pre-existing pool. It discovers pools from PoolCreated at or after the start block, and every Uniswap pool on the chain predates any fork (WETH/USDG 0.05 % was created at block 169 464). The pool table is empty on a fork unless something creates a pool on it, and with no WETH/USDG pool to seed priceCache, a WETH-quoted pool prices at zero. Radar's pool leg is served from a chain snapshot instead - see the API below.

Configuration and health

Ponder reserves /health, /ready, /status and /metrics for itself; registering our own /health is a build error. src/api/index.ts adds /healthz for a parseable { ok: true }, serves the GraphQL endpoint at / and /graphql, and the read-only client protocol at /sql/*. Gate traffic on /ready, which only turns 200 once the historical backfill is complete - /health is 200 as soon as the process is up.

apps/api/src/indexer/queries.schema.test.ts is the guard between the two packages: it reads ponder.schema.ts, collects every column an onchainTable declares, and fails when any leaf field in a GraphQL document of queries.ts is not one of them. It is a regex, not a parser - it does not know which table a field belongs to - but that is enough to catch a query asking for a column the indexer never stored, which is the class of bug that used to reach the browser as an empty card.

The API

apps/api is one Fastify process on PORT 8790. loadConfig parses the environment once into a Config and buildApp(config, deps) takes every dependency injected, so the routes cannot tell a test's fakes from server.ts's real wiring, and no module reads process.env on its own. Everything optional degrades rather than failing: no DATABASE_URL means in-memory repositories (no database), no reachable indexer means routes answer with empty data and /health reports indexer: 'down', and VENUE defaults to sim. Two things do not degrade: NODE_ENV=production without CORS_ORIGIN is a ConfigError before the socket opens, and TRUST_PROXY is off unless set.

Routes

The list below is everything the API serves; every route apps/web/lib/api.ts types is in it, plus /perp/bind, /perp/positions/:address and /points/recompute, which the web does not call.

Every error is {error, code}: bad_request 400, unauthorized 401, forbidden 403, not_found 404, conflict 409, rate_limited 429, unavailable 503, and a route-specific code where one helps (invalid_address, stale_ts, nonce_used, duplicate_thesis, manifest_missing).

The wire contract

The web's wire shape is the API's contract, and the API adapts to it. apps/web/lib/api.ts types every response; apps/api/src/routes/types/web.ts is a mirror of those interfaces, and web.types.test.ts reads both files and fails when a field is renamed, added or removed on either side. The API's domain models keep their own conventions - whole percents, Usd and Pct suffixes, indexer row names, {items, nextCursor} paging - and map on the way out: toRadarWireRow in radar.ts, toPortfolioWire in portfolio.ts, and routes/wire.ts for everything else. Two conversions recur and are easy to get backwards: the API's percent fields (funding1h, change24hPct) are whole percents and the web takes fractions, and a candle's t is unix milliseconds while the wire's time is unix seconds for lightweight-charts.

The guard catches renames, not semantics. Three places where the two sides agree on names and not yet on meaning: the web's api.perp.* fetchers do not build the auth envelope the routes now require, so the live perp path only works with VENUE=sim until they do; the web types the mirror response as MirrorPlan while the API answers { thesis, action }; and the web posts {email, message} to /contact where the route reads name, concern and an optional handle. All three are on the launch list.

Radar

buildRadar is a pure function over two inputs: indexer pools with 24 h stats and market stats from the feeds. A pool names a row through the non-numeraire side of its pair (USDG wins over WETH as the quote; WETH/USDG names the ETH row), joined to a Lighter market through @kerf/abi's TOKENS. A freshly launched token with no perp and no entry in TOKENS still gets a row from the ERC-20 symbol the indexer resolved. Assets Lighter lists but no pool trades get hasPool: false, and vice versa - the table is the union of the two venues, not the intersection.

Among a symbol's pools the best one is the highest fee APR, but only pools holding at least BEST_POOL_TVL_SHARE (1 %) of the symbol's total pool TVL compete, because a dust pool with a few swaps posts an absurd fee-to-TVL ratio and the trade page resolves the exact pool the row names. established is isEstablished on the best pool. The wire's basisSignal chip follows four rules: both legs present gives lp-and-short when the carry clears the watch bar and neutral otherwise; perp only gives long-perp; pool only gives neutral for an Established asset and avoid for an unproven one; neither gives avoid. Rows sort by pool TVL, then symbol.

When the indexer has no pool rows - it is down, or it is running against the public RPC and cannot see the pools that predate its start block - the route reads the pools straight from the chain. chain/poolSnapshot.ts asks the v3 factory for every (asset, USDG) and (asset, WETH) pair in TOKENS on each of the four fee tiers, and each pool's tick, liquidity and balances, in Multicall3 batches. chain/poolStats.ts adds the half a single block cannot answer: a rolling, incremental ring of hourly buckets built from the pool's own Swap logs, so 24 h volume, fees, trade count, the pool's age and the asset's market cap are real once a pool has enough coverage. Until then the row carries statsKnown: false and Radar reports lpApr: null and established: false rather than a fake 0 %. server.ts warms the snapshot at start and every 60 s so no request waits on it.

Market data

MarketData is one cached, fallback-chained view of every symbol. Lighter REST is the source of truth - market stats from /api/v1/orderBookDetails, the current funding rate from /api/v1/funding-rates (one row per reference exchange; only exchange: "lighter" is Lighter's own) - with the WebSocket stream filling gaps between polls. A crypto symbol with no Lighter mark falls through to Hyperliquid; a stock, index or commodity falls through to Yahoo. A symbol nothing answers for is still returned with mark: null and source: 'none', so Radar and the market list never silently lose a row. Funding and open interest exist only on Lighter; a fallback row keeps them null. Candles follow the same order, and Yahoo's 4 h bar is folded from its 60-minute bars because it has none of its own. A thundering herd collapses into one upstream round trip.

Portfolio

computePortfolio is pure; the route fetches its inputs in parallel and hands them over. The indexer supplies positions, vault shares, range orders and enrollments; the venue supplies perp positions and the account; pools come from the indexer for symbols and the current tick, and any pool the indexer has no row for (created before its start block) is read from the chain with readPoolMeta so the in-range flag still works. The USD figures the indexer does not store - valueUsd, costBasisUsd, feesEarnedUsd, amountInUsd - are computed in IndexerClient from the raw amounts plus current marks, which makes every one of them a live-price approximation: cost basis in particular uses the entry ratio against today's price of token1, because there is no historical price archive to do better.

Vaults and launch

Neither route is in the design spec's route list; both are read-only conveniences the web already has fixtures for, and every write on /yield and /launch goes straight to the contracts, so a stale or empty answer degrades the page to its fixtures rather than blocking anything. GET /vaults returns one card per manifest vault plus one per graduated token (named Kerf <symbol> Vault from the token's ERC-20 metadata), with apr24h/apr7d computed by computeVaultApr from the vault's own harvest log - null when there is no harvest in the window, never a misleading 0 %. feeYield is the one field the route never fills: it would need the sleeve's harvest history back to the note's inception. GET /launch selects tracked tokens from the indexer's pools and graduations (at most TRACKED_CAP, 50), then reads firstSeen, minLiquidity, each perp market and the insurance fund from the chain; the caller's open pre-market positions are the one address-dependent part and are read fresh every time.

Theses

A thesis is a signed claim about a position. POST /theses verifies an EIP-712 signature under the domain { name: 'Kerf', version: '1', chainId } over Thesis { positionRef, side, text, ts } - the market is derived or supplied metadata and is not signed, because what the author commits to is a position and a claim. positionRef is v3:<tokenId>, perp:<venue>:<market>:<id> or vault:<address>; side is long, short or lp; text is at most THESIS_MAX_TEXT (500) characters; ts must be within THESIS_TS_SKEW_SECONDS (300) of the server clock. The signature is good for one post: ts is part of the message, so (author, ts) identifies it, and a repeat is 409 duplicate_thesis - enforced under a race by the theses_replay_unique index. The leaderboard ranks authors by realised fees plus realised PnL across their indexed positions.

POST /theses/:id/mirror never executes anything. It returns the calldata (or the venue order) the client signs and sends itself: for a v3 ref, zapMint on the manifest's zapV3 with the author's pair, fee and ticks, amountIn 0, maxSlippageBps MIRROR_SLIPPAGE_BPS (100), a deadline MIRROR_DEADLINE_SECONDS (20 minutes) out and the numeraire as tokenIn; for a vault ref, deposit(0, address); for a perp ref, a market OrderRequest with size 0. Amounts are left at zero for the client to fill in: the author's size is their business, the mirrorer's is theirs.

Perp proxy and its authentication

Every /perp/* route is a thin forward to the configured venue. VENUE=sim is SimVenue, an in-memory book priced off the real marks: every new account is credited SIM_STARTING_EQUITY (10 000 USDG), market orders fill SIM_SLIPPAGE_BPS (5) away from the mark in the taker's disfavour, limit orders rest until the mark crosses them, maintenance margin is half of initial and funding accrues hourly from each market's funding1h. VENUE=lighter is LighterVenue, an HTTP client for services/signer (SIGNER_URL, shared SIGNER_SECRET in x-signer-secret) that forwards /onboard, /bind, /order, /cancel, /account/:address, /positions/:address, /orders/:address and /withdraw-intent. The API never holds an order key, and there is deliberately no withdraw route: /perp/withdraw-intent returns the payload the user's wallet signs, and on the sim venue answers 503 sim_no_withdraw. The rest of that trust model is in Perps via Lighter.

Every write body carries an envelope next to the route's own fields: auth: { nonce, ts, signature }, signed with signTypedData over PerpAction { action, account, payloadHash, nonce, ts } under the same domain the theses use. payloadHash is the keccak256 of the canonical JSON of the body without auth - keys sorted recursively, no whitespace, undefined dropped - so the wallet signs the exact order it is sending and a signature from one body cannot be attached to another. action is fixed per route (onboard, bind, order, cancel, withdraw-intent); the client does not choose it. requirePerpAuth checks in this order and for this reason: a well-formed address (400), a well-formed envelope (401 unauthorized), |now − ts| ≤ PERP_AUTH_TS_SKEW_SECONDS (300, else 401 stale_ts), the signature recovers to address over this body (401), and finally that (address, nonce) was never seen (409 nonce_used). The nonce is consumed last, only for an envelope that verified, so a forged request can never burn a nonce the real signer is about to use. A nonce row outlives the window by NONCE_EXPIRY_SLACK_SECONDS (60) and is then safe to drop, because after that the envelope is stale_ts before the nonce is ever read. The pure half - the message and the canonical hash - is @kerf/core's perpAuth.ts, which the web imports too, so neither side can drift.

Referrals and points

GET /referral/:address returns the code the address registered, the referrer it is bound to, and earningsUsd: the indexer's per-token earned totals priced with the same market marks every other route uses, USDG pinned at 1, a token nothing prices contributing nothing rather than its raw amount. referredCount is always 0 today - the route passes three arguments where the mapper takes four - and is on the launch list.

Points are a ledger, not a token: POINTS_PER_USD_VOLUME 1, POINTS_PER_USD_FEES 5, and volume counts THESIS_MULTIPLIER (2×) while the address has a thesis less than THESIS_LIVE_SECONDS (7 days) old. They are always recomputed from points_events rather than incremented in place, so a replay is idempotent; POST /points/recompute behind ADMIN_SECRET rewrites every total. Nothing in the API writes a points event yet - addEvent is called only from tests - so every live total is zero until the ingestion job on the launch list exists. The money side of both is in Fees & referrals.

Rate limits and hardening

Every POST, PUT, PATCH and DELETE shares one sliding-window budget of RATE_LIMIT_WRITES_PER_MIN (30) per (route group, client IP), where the route group is the first segment of the matched route pattern - /perp/order and /perp/cancel share /perp, and a client cannot mint fresh budget by varying :id. The hook runs onRequest, before the body is parsed, and a refusal is 429 with a Retry-After in whole seconds. Reads are never limited. /contact keeps its own stricter limiter on top: CONTACT_LIMIT 5 per CONTACT_WINDOW_MS (60 s) per IP. The limiter is in-process, so two replicas each grant the full budget; a multi-replica deployment needs it backed by Postgres or Redis. TRUST_PROXY decides what request.ip is and is off by default, because trusting X-Forwarded-For with no proxy in front lets every client choose its own limiter key. CORS_ORIGIN is a comma-separated list of scheme-plus-host origins; * and bare hostnames are refused, and reflecting any origin is a development convenience loadConfig refuses in production.

Running without the API

The web runs without any of this. Each page hook in apps/web/lib/data.ts wraps its fetcher in React Query with no retry and a 15 s stale time and falls back to a fixture from lib/fixtures/ when the request fails, including the status-0 network error of an API that is not there. The returned isSampleData flag is what a page renders as the "Sample data" tag; it is true whenever what you are looking at came out of a fixture. The sample portfolio, referral and points belong to one SAMPLE_ADDRESS, and any other address gets an empty one so ?as=0x… never claims someone else's positions. On the API side the same idea is InMemoryIndexerSource, the in-memory repositories and SimVenue. What the web cannot fake is a contract: without a manifest every write button renders disabled.

The bots

The three bots live inside the API process and are opt-in by environment: startBots returns null, after logging which one is missing, unless BOTS, BOT_PRIVATE_KEY and MANIFEST_PATH are all set. A bot is one tick() away from doing nothing: it reads the world, decides, and returns a flat list of BotActions, each of which is a transaction hash, a venue order id or a skipped reason - a tick that decides to do nothing still says so, which is what makes the log worth reading. The runner's rules are that a bot must never be able to take the API down: every tick is wrapped, every rejection is logged and dropped, a tick still running when its interval comes round is skipped rather than stacked (three overlapping keeper ticks would be three transactions racing for one bounty), timers are unref'd so a SIGTERM never waits on them, and every bot runs once immediately at start.

The keeper

One tick does three sweeps in order. (a) Enrolled positions: the indexer's active enrollments, then one shouldHarvest and one shouldRebalance per position batched through Multicall3, then harvest or rebalance for the ones that say yes. The views are the contract's own opinion, so the bot never re-implements the policy - @kerf/core's shouldHarvest exists for the UI to predict the same answer, not for the bot to second-guess it. The bounty is bountyBps of the indexer's uncollectedFeesUsd, the same figure for a rebalance because it collects the same pending fees. (b) Range orders: fillable(orderId) for every open order, then fill; no fill is attempted without a yes, since the contract would revert anyway. The bounty is RANGE_ORDER_BOUNTY_BPS (100) of amountInUsd. (c) Vaults: LPVault.harvest() has no cheap "is it worth it" view, so the bot blind-simulates it once per VAULT_HARVEST_INTERVAL_MS (6 h) per manifest vault; the simulation costs nothing and the vault's own minInterval rejects the rest.

Bounties fund the gas. Sweeps (a) and (b) price theirs in USD from the indexer and convert to wei at the ETH mark, because the rule is denominated in the gas token. When any input is missing the bounty is null and the action is skipped, not sent blind: a missed harvest costs the user nothing (the fees stay in the position and the next tick retries once the price is back), while "send if it simulates" once turned a market-data outage into a tick of unguarded gas for every enrolled position. Sweep (c) is the one deliberate blind send and declares itself with bounty: { kind: 'none' }, which is a different thing from a null bounty.

The one send path

Every bot write goes through ChainClient.simulateAndSend, in this order. First simulateContract, an eth_call against pending state; a revert here is the normal case, not an error - shouldHarvest was stale, the order is not fillable yet, graduate says TooYoung - and it is why bots are safe to run on a loop. Then, for a bounty-funded action, estimateContractGas × getGasPrice is the wei the transaction will cost, and the send is skipped when bounty < gasCost × GAS_BOUNTY_MULTIPLE (3): a keeper that clears $0.90 of bounty for $0.80 of gas is a slow way to lose money, and the margin has to absorb a base-fee spike between the estimate and the block. A null bounty skips before the estimate. Then writeContract, one confirmation, and a reverted receipt reported as a failure so the caller's backoff kicks in.

ActionGuard is the idempotency layer, keyed by (kind, target): after a success the pair is muted for COOLDOWN_MS (5 min), because the chain state that triggered it takes a moment to reach the indexer and re-sending would burn gas racing our own transaction; after a failure - a revert, or a bounty that never clears the floor - it is muted for FAIL_BACKOFF_MS (15 min), so a position that reverts every time costs one simulation per quarter hour instead of one per minute. The state is in-process on purpose: a restarted bot re-deriving everything from chain and indexer state is the correct behaviour, and the on-chain minInterval is the real guard. It also means two API replicas would double-send; bots belong on one replica.

The viem chain definition the client is built from must declare contracts.multicall3. Without it viem's multicall throws, readMany silently degrades to one HTTP call per read, and the Radar pool snapshot goes from one second to ninety-six.

The hedger

A HedgedLPVault is an LP position plus a short that cancels its price exposure, and the LP leg's delta is not a constant: as the price walks through the range the position converts between token0 and token1 continuously, so the short has to be re-sized. Once per vault per tick the hedger reads the vault's positionTokenId(), the NPM's positions(tokenId) for liquidity and ticks and the pool's slot0() for the price; lpDelta from @kerf/core gives the token0 balance, which is the risk asset (NVDA in an NVDA/WETH vault) - token1 is the numeraire and carries no delta worth hedging. It compares that target with the short already held on the venue, and only acts when a report is due (HEDGE_REPORT_INTERVAL_MS, 15 min) or the drift exceeds HEDGE_DRIFT_BPS (200) of the target - a fast move must not wait for the cadence. hedgeOrders applies the dead band, the venue lot size (HEDGE_LOT_SIZE 0.001, rounding down so rounding never over-hedges) and the minimum notional (HEDGE_MIN_NOTIONAL_USD 50), and returns zero or one order, which goes to the venue - Lighter through the signer, or the sim. Finally reportHedge(notionalUsd, unrealizedPnlUsd, equityUsd, asOf) puts the venue state on chain in USD × 1e6 with asOf as the bot's clock, which is what the vault's totalAssets() and its staleness pause are built on. Reporting pays no bounty; it is the price of running the vault, so it sends whenever it simulates.

The vaults it works are the manifest entries whose name contains "Hedged" plus the HEDGED_VAULTS override, and the market is the Lighter symbol for the pool's token0 unless VAULT_MARKETS names another. The seed vaults are deployed with maxHedgeAge of 6 hours, so a 15-minute cadence leaves room for many missed reports before deposits pause; the comment in hedger.ts still says 1 h, which was the earlier spec value - the deploy constant in KerfWiring is the one in force. What the hedger key can and cannot do is the subject of Hedged vaults & trust model.

The graduator

LaunchPipeline is deliberately half off-chain: the contract checks age and pool liquidity, while the rest of Established (market cap, trade count) is a flag the indexer computes, and this bot is the join. For every pool the indexer flags Established whose launch token - the non-numeraire side - has not graduated, it reads firstSeen(token) in one batch. Zero means track(token), which starts the on-chain three-day clock; GRADUATION_AGE_SECONDS (3 days) elapsed means graduate(token), which deploys the token's LPVault; anything in between is nothing, quietly, because there is nothing to say every minute. Neither call pays a bounty, so both go out with { kind: 'none' }. graduate reverting with ThinPool, TooYoung, NotTracked or AlreadyGraduated is the expected outcome for most candidates on most ticks, so those are logged as skips rather than warnings, and the guard's failure backoff keeps them from being re-simulated every minute. The contract half is in Launch & pre-market perp.

Read the code

• apps/indexer/ponder.config.ts sources, start blocks, the no-manifest fallback
• apps/indexer/ponder.schema.ts every table and column, with its comment
• apps/indexer/src/logic/ pricing, tvl, stats, uptime and the Kerf state machines
• apps/indexer/scripts/smoke.sh anvil fork → deploy → canary → ponder → GraphQL asserts
• apps/api/src/app.ts buildApp, the write budget hook, the error shape
• apps/api/src/radar.ts buildRadar and toRadarWireRow
• apps/api/src/chain/poolSnapshot.ts Radar without the indexer
• apps/api/src/perp/auth.ts requirePerpAuth, the order of checks
• apps/api/src/theses/service.ts create, leaderboard, mirror
• apps/api/src/routes/wire.ts domain model → wire shape
• apps/api/src/routes/types/web.types.test.ts the drift guard
• apps/api/src/indexer/queries.schema.test.ts every GraphQL field against the schema
• apps/api/src/bots/chain.ts simulateAndSend and the gas rule
• apps/api/src/bots/keeper.ts the three sweeps
• apps/api/src/bots/hedger.ts lpDelta → hedgeOrders → reportHedge
• apps/api/src/bots/graduator.ts track and graduate
• apps/web/lib/data.ts the fixture fallback and isSampleData