FULL GUIDE HOW TO CREATE REAL TRADING TERMINAL FOR ROBINHOOD CHAIN
Four blobs move through an isometric village. One of them walks into a building labeled LAB. A circular progress bar starts filling. A second later, a green number appears: +1 PTN.
To the player, it looks like a simple character upgrade.
What actually happened: the agent's thinkingBudget increased from 512 to 1500 tokens. The next time it analyzes a memecoin on Robinhood Chain, it gets almost three times more reasoning space before making a decision.
On Pons, where the vast majority of launches never make it through the bonding curve, that matters. A few extra seconds of reasoning can be the difference between spotting a suspicious token early and buying straight into a rug.
The player never touched YAML. They never opened a terminal. They never changed a config file.
They moved a progress bar, upgraded a stat, and changed how a real trading agent behaves.
That is the entire idea.
Every stat you see in the game corresponds directly to a parameter the trading engine reads at runtime. Every building controls a subsystem that raises the limit of that parameter. Every temporary boost is just an override that would normally be written manually into a config file.
The game itself is free. The infrastructure behind it is not.
Depending on the number of agents, models, reasoning depth, scan frequency, and tools enabled, running a full desk can cost anywhere from around $10 to several hundred dollars per day.
And every player is competing under the same deterministic market conditions.
Same launches. Same prices. Same seed. Different configuration.
This article shows how both layers work: the game on top and the trading engine underneath, with code, cost breakdowns, and a leaderboard you can submit to immediately.
The number that makes this interesting
Robinhood Chain saw roughly $1.5 billion in DEX volume on September 1, 2026, putting it ahead of Ethereum, BNB Chain, and Base for the day, with only Solana higher.
Pons, the chain's main token launchpad, has also been producing unusually high activity. More than 20,000 tokens can appear in a single day.
But only a tiny percentage survive the full bonding curve. Out of roughly 208,000 launches, only about 1,300 reached graduation. That is close to a 1% success rate.
The other 99% died before they ever became real markets.
That is exactly why the agent configuration matters.
A game where every second pick works gets predictable fast. But when only around one in a hundred makes it through, every choice carries weight. Every upgrade matters. Every token you ignore could be the one that survives. That is what makes the simulation feel like a game instead of a stats screen.
The idea in one line
Upgrading an agent is just changing a live trading config through a game interface.
Four bars, four fields
Every agent runs on Opus 5 from the very first tick. PTN does not upgrade the base model - it expands the context window and gives the agent more reasoning time. Once PTN reaches 12, Fable 5.1 becomes available as an additional layer.
const MODEL_LADDER = [
{ minPtn: 0, id: "claude-opus-5" }, // everyone starts here
{ minPtn: 12, id: "claude-fable-5-1" }, // earned, not given
];
const thinkBudget = ptn =>
ptn >= 12 ? 3000 : // deep chain-of-thought
ptn >= 8 ? 1500 : // moderate reasoning
ptn >= 4 ? 512 : // light thinking
0; // raw instinct
function compileConfig(stats, level, boosts, baseSizeEth = 0.01) {
const tier = [...MODEL_LADDER].reverse().find(t => stats.ptn >= t.minPtn);
let pollIntervalMs = Math.max(400, 3200 - stats.spd * 260);
let ctxCandles = Math.min(120, 24 + stats.ptn * 6);
let thinkingBudget = thinkBudget(stats.ptn);
let positionSizeEth = baseSizeEth * (1 + stats.rsk * 0.18) * (1 + level * 0.12);
const slippageBps = Math.max(30, 160 - stats.gas * 9);
if (boosts.overclock) pollIntervalMs = Math.max(200, Math.round(pollIntervalMs / 3));
if (boosts.alphaFeed) { ctxCandles *= 2; thinkingBudget *= 2; }
if (boosts.leverage) positionSizeEth *= 2;
const maxSizeEth = baseSizeEth * 8; // hard cap. the one thing the game cannot raise.
return {
pollIntervalMs, model: tier.id, ctxCandles, thinkingBudget,
positionSizeEth: Math.min(maxSizeEth, positionSizeEth),
slippageBps, maxSizeEth,
};
}The cost of these decisions is not theoretical. Move PTN from 3 to 8 in the FORGE tab and watch the compiled config update in real time:
PTN MODEL CTX THINK $/DECISION $/DAY
0 OPUS 5 24 off $0.0040 $10.64
4 OPUS 5 48 512 $0.0183 $48.15
8 OPUS 5 72 1,500 $0.0444 $117.01
12 FABLE 5.1 96 3,000 $0.1667 $439.16
That table is not a static reference. It updates live inside the game as you move the slider. Push PTN to 12 and the cost jumps to $439/day, forcing the player to decide whether deeper reasoning is really worth nearly 40x more. That single choice explains API economics better than a page of documentation.
One system, two ways to run it
Six phases drive the loop: REST, TRAIN, SCAN, DECIDE, HOLD, SETTLE.
In the village, those phases become animation. Agents move between buildings, gather around the terminal, flash BUY or SELL signals, and level up with visible effects.
On the trading side, the same phases run as real execution logic. Agents read Bitquery data, call Claude, manage positions on the Pons curve, settle results, and rebuild the config.
Same state machine. Same core function. Switching between simulation and live mode takes one line:
const market = mode === "sim"
? new SimMarket(42) // seeded random walk, free, deterministic
: new PonsMarket(BITQUERY_KEY); // Robinhood Chain, chain 4663, real data
const brain = mode === "sim"
? heuristicDecide // momentum + noise scaled by PTN
: claudeDecide(ANTHROPIC_KEY); // Opus 5 or Fable 5.1, temperature 0
runAgent(agent, market, brain); // everything above is sharedThe brain contract
Both sides honor the same shape:
{ action: "BUY" | "SELL" | "SKIP",
sizeEth: 0.031,
confidence: 0.72,
holdTicks: 34,
reason: "reserves rising, dev wallet quiet" }The simulator produces this output from a deterministic formula. The live desk gets the same shape from a Claude response. But three rules inside the live brain are hard requirements:
> Errors always resolve to SKIP. A parse failure, timeout, rate limit, or broken response should never turn into a trade. If something goes wrong, the agent does nothing.
> sizeEth is capped after the model answers. Let the model suggest a position size, then enforce the limit in code. Never let the model control exposure directly.
> temperature: 0. Decisions need to be repeatable. If you replay a session to understand why an agent made a bad trade, you want the same input to produce the same reasoning path.
These are not cosmetic implementation details. They protect against the exact behavior that destroys autonomous trading systems: oversized positions, bad reversals, and unexpected actions when the model or API fails.
Alpha Arena showed how expensive those mistakes can become. Grok suffered heavily from aggressive longs without enough protection, while GPT struggled with reversal timing. A strict position cap and a default-to-SKIP policy are simple safeguards against both.
Live brain: Claude running on Opus 5
const SYSTEM = `You are a memecoin trading agent on Robinhood Chain (Pons).
Hard facts:
- 99 of 100 Pons tokens die on the bonding curve.
- Gas is subsidized. Wash trading is free. Buyer counts inflate easily.
- Your job is capital preservation first, opportunity second.
Reply ONLY JSON, no prose:
{"action":"BUY"|"SELL"|"SKIP","sizeEth":number,"confidence":number,
"holdTicks":number,"reason":string}
If you are not confident, SKIP. A missed trade costs nothing.`;
const CLASS_LENS = {
SCOUT: "You favour early entries. Age under 8 minutes interests you.",
SNIPER: "You favour precision. Skip more than you trade.",
WHALE: "You favour size on high conviction only. Curve above 40% is your zone.",
ARB: "You favour short holds and small edges. Exit fast.",
};The class lens is what turns SNIPER and WHALE into genuinely different agents once the live engine takes over. In simulation, the difference comes mostly from their starting stats. In live mode, the difference is also encoded in the prompt. Same underlying system, different behavior depending on how that agent is framed.
The multiplayer layer
Every player runs the same backtest: seed 42, 7,000 ticks, fixed market path, fixed RNG.
If two players use the same stats and the same strategy, they should land on the same result all the way down to the final decimal.
That is what makes the leaderboard useful.
You are not competing against luck. You are competing against configuration.
A better threshold. A better stat spread. A better class mix. A better use of reasoning budget.
Two leaderboards run at the same time:
BUILDS ranks players by backtest P&L. This is the pure optimization board. Everyone sees the same market and tries to squeeze more performance out of it. The leading build is visible, including its stats and strategy. Tap it, load it into FORGE, change something, and try to beat it.
VILLAGES ranks live sessions by net P&L. This board reflects the full economy: how you trained agents, where you spent upgrades, which classes you deployed, and how well the desk performed in real conditions. It refreshes automatically.
A small rival panel stays visible above the speed controls. It shows the top three players and how far ahead or behind you are.
So even when nothing dramatic is happening on screen and your agents are just moving through the village, the competition is still there.
The loop becomes simple: find the leader, copy the build, change one thing, run it again, take first place, then watch someone else copy you.
The metagame keeps moving because every new configuration becomes another baseline for everyone else to improve.
What the player never needs to see
An agent with SPD 3, PTN 8, RSK 5, GAS 6, level 4 might compile into something like this:
pollIntervalMs 2420
model claude-opus-5
ctxCandles 72
thinkingBudget 1500
positionSizeEth 0.0176
slippageBps 106
costPerDecision $0.0444
dailyBurn $117.01
The player never has to think about any of those fields.
They see four stat bars, a win rate, a P&L number, and a few upgrade choices.
The operator sees the runtime config that gets passed into Bitquery, Anthropic, and viem.
Same agent. Same parameters. Different interface.
No separate translation layer is needed because the game UI is already editing the real config.
Ten releases
Every drop upgrades both sides at once. The village gets a new mechanic, and the trading desk gets the system that makes it real. One release, one shared upgrade.
01 DEX TERMINAL live candles, order flow, open positions shipped
02 RUG PULLS reserve drain alerts, liquidity cliffs, exit signals
03 NEWS TICKER market events, sentiment shifts, volatility triggers
04 SKILL TREES class-specific prompts, tools, unlockable abilities
05 SECOND DEX cross-market price gaps, routing, arbitrage logic
06 LIQUIDITY POOLS LP positions, pool depth, impermanent-loss tracking
07 AGENT ROSTER hiring, rarity tiers, shared budgets, team control
08 MARKET CYCLES regime detection, changing conditions, visual cycles
09 RIVAL VILLAGE competing flow, dynamic slippage, shared opportunities
10 LIVE BRAIN real Claude decisions with reasoning shown in-game
Release 10 connects everything.
When an agent reaches the terminal, the game does not invent a fake animation or scripted message. The speech bubble can show the actual reason returned by the live model after evaluating the trade.
So the thing walking around the village is no longer just a game character. It is a visible interface for a real trading agent making a real decision. The village shows what the player understands. The desk runs what the machine needs. Both come from the same system.
Open FORGE and shape your own agent. Tune the stats, run the backtest, push the build to the arena, then watch other players clone it, tweak it, and try to take your spot.
When you are ready to go beyond simulation, add your Anthropic key to .env and switch MODE=live. The same agents stop reading a generated market and start pulling real data through Bitquery. The same decision loop stops using a formula and starts asking Claude what to do next.
Nothing else has to change.
The village, the agents, the stats, the loop, the leaderboard - all of it stays the same. Only the source of truth changes.
In sim mode, you are testing a strategy.
In live mode, you are watching that same system operate against real markets.
One codebase. Two modes. One environment variable between them.
Save this guide if you want to build your own setup, and subscribe if you want the next releases, new agent configs, live experiments, and updates as the arena gets closer to full live mode.
github.com/w1nklerr
