The keeper

The keeper is a Node service in keeper/. It takes launch requests and launches coins on the three chains. It talks to Solana through @solana/web3.js and to Robinhood Chain and BNB Chain through viem.

Modules

The API

Commands

Keys and configuration

Without the keys the keeper stays in dry-run mode and can only read and simulate.

The address lookup table, for a dev buy on pump.fun

create_v2 alone takes 849 bytes of the 1232 a transaction holds, so create and buy do not fit together. pump.fun's own site solves it with an address lookup table that replaces the 24 fixed accounts by one-byte indexes; with it the create and the buy are 828 bytes. Pivot does the same with its own table.

• node keeper/alt.mjs prints the accounts and the sizes, and sends nothing.
• node keeper/alt.mjs --create creates the table with the keeper wallet, once, for about 0.01 SOL, and saves its address in keeper/data/pump-alt.json (or set PUMP_ALT).
• Without the table the dev buy on pump.fun is switched off: the API says so (pumpDevBuy: false in /api/config) and the page disables the box. Nothing is ever sent as a create followed by a separate buy, because a failure between the two followed by a retry would create a second coin. Dev buys on Pons and Flap do not need it.

The float: how one deposit in SOL pays for three chains

The creator pays in SOL. The keeper pays the creation fees and the gas in SOL, ETH and BNB from a float it already holds on each chain, so nobody waits for a swap or a bridge while a launch runs. The deposits bring SOL in; the operator tops up the ETH and BNB floats in batches with that SOL.

• node keeper/treasury.mjs prints the three balances, the floors (1 SOL, 0.02 ETH, 0.04 BNB), the targets (5 SOL, 0.1 ETH, 0.2 BNB) and, below a floor, how much to top up and how much SOL of the deposits that is.
• The API reads the three balances (cached for a minute). When one is below its floor, POST /api/requests answers 503 "launches are paused for a few minutes while the keeper wallets are refilled", and no money is asked.
• A dev buy on Pons or Flap is fronted from the ETH or BNB float, so a large one needs a large float: the API refuses a dev buy that would take the float below its gas reserve (0.005 ETH, 0.01 BNB) and says which chain.
• The top-up itself is done by the operator with an exchange or a bridge. It is not automated in the keeper, on purpose: a swap that fails in the middle of a creator's launch is worse than a launch that waits.

What the dry runs prove

• The Solana creation and fee sharing configuration are valid against the live pump.fun program and state.
• The Robinhood path works against the real Pons: launch, buy, sell and sweep, with the engine's prediction equal to the chain's result.
• The BNB path works against the real Flap: the keeper's mined salt gives the address the Portal creates, the tax is the creator's fee, and harvest shares it between the creator's address and Pivot.
• The whole pipeline runs from a request to a registered coin against a fork and live Solana state.

What they do not prove

• A live run with real funds, which has not been done.
• The behaviour of the keeper through a long outage, an RPC failure or a pump.fun program change.
• update_fee_shares_v2 on a new coin: its layout comes from the AuronV2 code that ran it on mainnet, and a single transaction with the creation and both fee sharing instructions would exceed the size limit.

Public limits

• 12 launch requests and 20 uploads per hour and address.
• A deposit counts only if it comes from the Solana address given in the request and carries the request's reference.
• Public requests cannot change the pump.fun fee share, and there is no alignment buy and no maker cash.
• Pipeline steps never overlap: a request already being worked on is skipped by the next pass, so a step cannot run twice.