Test results
Four layers are tested: the Robinhood Chain contracts on a fork of the real chain, the Solana transactions by simulation on live mainnet state, the engine and the keeper's logic in node, and the whole launch pipeline in dry run.
Robinhood Chain contracts on a mainnet fork
11 tests, all passing, against the real Pons V2 contracts. Run forge test in contracts/.
| Test | What it proves |
|---|---|
| Keeper launches and wires the vault | One call launches the coin on Pons, creates the vault, funds it, and the coin opens at 1.68 ETH of virtual quote |
| Only the keeper launches, inputs are checked | Fee above 10 %, share above 100 %, a deposit below the Pons fee, a caller that is not the keeper: all revert |
| Keeper buy matches the curve maths | The tokens received match the constant-product formula within 0.3 % |
| Keeper sell returns ETH and cash | Half the tokens return a bit over half the ETH, as a convex curve should, and the proceeds are added to the vault's cash |
| Keeper cannot spend more than the cash | A buy above the maker cash reverts |
| Only the keeper can trade | buy, sell, sweep and retire revert for anyone else |
| Sweep only goes to the pool | ETH and tokens reach the pool address and nowhere else |
| Fees split between creator and pool | After 2 ETH of trades at a 3 % creator fee and a 50 % payout share: 0.037 ETH to the creator's address, 0.037 ETH to the pool |
| Without a creator address all fees go to the pool | The pool receives all of it |
| Retire after graduation | Cannot retire early, retire after a 5 ETH buy sends the cash and inventory to the pool, buy then reverts |
| Initialize twice | Reverts, only the launcher can initialize a vault |
Keeper path on a fork
node keeper/test-rh-fork.mjs runs the keeper's own Robinhood code against an anvil fork:
- launch through the launcher with a 1 ETH vault,
vault.buy(0.4 ETH)returned 189,189,189 tokens and the engine predicted 189,189,189,vault.sellof half returned 0.2121 ETH and the engine predicted 0.2121,- the engine's decision on the resulting pair,
vault.sweepreached the pool address.
Solana transactions on live state
node keeper/check-solana.mjs reads a live pump.fun curve and simulates, with signatures disabled and nothing sent:
- a buy of 0.5 SOL on the live curve,
- a sell by a real holder of that coin,
- a
create_v2for a brand new mint, - a
create_v2followed bycreate_fee_sharing_configin one transaction, so the sharing config is created for a coin that exists only inside the simulation.
All four simulate without error. The script also checks that the curve is a constant product on the initial invariant and that the supply is one billion.
The whole pipeline in dry run
node keeper/launch.mjs keeper/sample-launch.json against an anvil fork and live Solana state: the Pons launch is simulated by the real launcher, the pump.fun creation is simulated on mainnet, the alignment is computed (4.79 SOL on pump.fun), the fee sharing is planned and the coin is registered, in the order Pons, pump.fun, alignment, fee sharing, register.
Engine, keeper and pipeline in node
38 tests, all passing. Run npm test.
Engine (14):
- Opening values match the on-chain constants, 27.96 SOL and 1.68 ETH.
- In dollars pump.fun opens near $3.2K and Pons near $4.3K.
- Graduation points, fees, and the alignment on the cheaper side.
- Cash does not cross chains, inventory is per chain.
- The maker obeys the band, sells inventory of the rich chain first, closes a move of the SOL/ETH rate.
- A $5,000 pool keeps the coin in band at least 85 % of the time in a moderate market, no maker at most 30 %.
Keeper logic (6): plans become raw transaction arguments with slippage on the right side, the alignment is a pump.fun buy of a few SOL.
Operations (18):
- The pipeline runs in the order Pons, pump.fun, alignment, fee sharing, register.
- A failed Pons launch refunds in full and runs nothing else. A failed pump.fun creation leaves the coin on Pons and refunds minus costs. A failed alignment needs attention and refunds nothing.
- A transient failure is retried. After a crash the pipeline resumes and never repeats a finished step.
- A deposit below the amount does not start a launch, a request without a deposit expires.
- The rate is the median of the sources and a source that disagrees raises a flag.
- Guards block a trade above the cap, a dust trade, stale data, a bad rate, the kill switch, a coin over its budget and a tick over its cap.
- A deposit transaction is read as sender, amount and memo, and only the right reference matches.
- The metadata upload posts the image and fails loudly on a bad answer.
- The API validates parameters, quotes a deposit, refuses to quote when the rate sources disagree, and moves a request to done once a deposit arrives.
What the tests do not cover
- A live run with real funds on either chain.
- A very large buy that opens a gap bigger than the pool.
- The keeper through a long outage or an RPC failure.
update_fee_shares_v2on a new coin.- An independent audit. See status.