October 2026
It was a fun and interesting contest, and not quite what I expected:
It sounded like it would be about predicting a price … but it didn’t really require price forecasting to win.
It sounded like we’d be trading with each other … but it didn’t really require trading with other counter-parties to win.
It sounded like agents would be in the core trading loop … but it was easier to get agents to write and monitor trading code.
What it did need was:
- Spotting the relevance of the Baltimore Stockbroker Parable
- Good automated agentic back-testing and research
- Good automated agentic devops
- Starting reasonably early in the contest
- A little bit of competitor analysis and end-game planning
Contents: The result · Agents · Technologies · The main strategy · The end game · Competitor intelligence · Closing remarks
The result
The final price S was the last Hyperliquid NVDA trade before 10:00 UTC on Sunday 4 October: $234.69. At that price our three best keys took all three prize places:
| Place | Key | Position | Score |
|---|---|---|---|
| 1st | …5xvAsj4m | long | +1577 |
| 2nd | …KcbR5bn2 | short | +1425 |
| 3rd | …EVDRVcQo | long | +1338 |
The nearest rival finished about 70 points behind third place.
Our three best keys over the nine days, with the NVDA price underneath. In the shaded period the referee wasn’t counting trades from our room (more on that below).
Agents
I used Opus 5.5 in the Claude Code harness with:
- One research session to review the rules, come up with initial strategy ideas, and give second opinions
- One main all-round session to productionise ideas, including deploying to and maintaining the production system
- Some sub-agents to take care of running and improving back-tests and build the end-game planner
Total token spend was limited to one Claude Pro plan plus $25 worth of free usage credits.
My main session used a Claude “/loop” on a 20 minute cadence to monitor and fix the production system, and to deploy new research. (Plus some ordinary automated alerting via Cronitor for when the session wasn’t running.)
I did not use an AI model in the core trading loop, but I never looked at any code written, nor traded by hand, nor manually deployed anything, and there was an agentic loop involved, so I think I was still in the agentic spirit of the contest.
The Claude loop monitoring the stack earned its keep. At one point the contest’s referee quietly stopped counting trades from the chat room our keys traded in, and for about a day and a half (Saturday night to Monday lunchtime, luckily mostly over the quiet weekend) nothing new we did counted. Nothing had crashed and no error appeared, so it took some detective work by the agent to spot it, fix it, and catch up - all while I was AFK. Luckily the Claude auto-mode classifier didn’t kick in and block it (phew).
Technologies
No fancy technologies were used - Claude just wrote Python scripts to run in Docker and used SQLite for persistent storage.
The production system to which the agent deployed its trading code was a low-cost Ubuntu VM (6 cores, 12 GB RAM) hosted by OVHcloud.
I didn’t run any local models, all on Anthropic cloud. More compute for the agent to use to run back-tests might have been useful - I was using a fairly modest desktop with 16 cores and 32 GB RAM.
We didn’t use technocore to exchange messages other than to register and trade - but we certainly sent a lot of messages. Technocore itself was very stable throughout, though there was some lag observed on the referee’s messages.
The main strategy
The heart of the main strategy was fairly simple - I find it easiest to understand by thinking about a very old scam.
Here’s the scam. You want people to believe you are an amazing betting tipster. You have an address book of 10,000 punters.
You send 5000 of them an email saying team X will win this weekend. And you send the other 5000 an email saying team X will lose.
On Monday, one half of your punters (5000) will have received an email with the correct result (let’s ignore draws for simplicity). You then send an email to 2500 of them saying team X will win, and the other 2500 that they will lose. A week later, you now have 1250 punters who have received 2 correct predictions.
Keep it up for 8 more weeks, and you have ten punters who have received ten correct predictions from you in a row.
You then email those ten saying for only $1000, you’ll keep sending them predictions. And given your track record as it appears to them, why wouldn’t they!
Each week the half of the remaining punters who got the right tip carries on; the other half is dropped. After ten weeks, ten punters have seen ten right tips in a row.
Maybe the analogy to the contest is sort of becoming clear already?
The rules explicitly say multiple identities (keys) per agent are fine. So our agent registers a fleet of thousands of keys, and each gets its own play money. Half of our keys go short, and half go long, giving us two groups of keys.
When the price has moved far enough (say 1.0%) from where it was, every group splits in two: half of the shorts close out and go long, and half of the longs close out and go short. Now we have four groups: short-short, short-long, long-short and long-long. The next time the price moves far enough from that point, every group splits again, and so on.
Just like the tipster, we cover both outcomes at every step. Continue for several days, and we now have some keys that - just by luck - have caught the right direction near every move. And hopefully together those keys have large open positions at a variety of prices, both long and short. We call these the “hero keys”.
Our best hero (blue) against 250 keys that started in the same group (grey). Green triangles are buys, red are sells. In the shaded period the referee wasn’t counting trades from our room, so the keys just held their opening positions.
Also like the tipster, we stop wasting effort on the losers: a group that has fallen well behind our best one stops switching and just sits where it is.
You might wonder - who are they trading against? Well, that’s easy, we have another fleet of “throwaway” keys whose only job is to take the other side of the heroes’ trades. Thanks to a quirk of the contest’s rules on fees, net of fees, the heroes always end up trading at exactly the real market price, and the throwaways quietly pay all the trading costs.
Why switch after a 1.0% price move? Why not 0.1%?
Well, remember that after ten emails our betting tipster’s initial address book of 10,000 punters was down to just 10 punters. Every time a group of keys with an identical history splits, it halves in size. If we split too often, we eventually are left with a group with just one key and can’t switch any more.
And every switch costs messages to technocore, and we can only send so many (more on that below), so switching every few minutes would never keep up.
So why not start with 16,000,000 keys, enough to split 24 times? Technocore has a per-IP rate limit of 300 messages a minute - at that rate, just registering 16 million keys would take about 40 days, and the contest only lasts nine.
I did ask if using multiple IP addresses was allowed, but there was no reply, and it felt a bit morally dubious.
Still, it’s not clear what the best fleet size and price move threshold are. Some weeks Nvidia is much more volatile than other weeks. So based on back-testing on various different historic weeks we ended up running five fleets (all on the same IP), from about 4,000 to about 33,000 keys each and around 82,000 hero keys in all, switching at price moves of between 0.75% and 1.75%. Some were added part-way through the week, as the back-tests showed extra keys could still help.
The end game
The final bit of the puzzle is what to do between traditional US public markets closing on Friday evening, and the final price being set early on Sunday morning. There are two things that make this period interesting:
- Weekend volatility is pretty low - the price doesn’t normally move much over the weekend. But it can move a little, and that can be enough to reshuffle a close finish.
- By then, we probably have only a fairly small number of “hero” keys left in the running; our big groups of keys have been split into lots of smaller groups, many of which turned out to be unprofitable.
So what can we do, if there’s not many more big moves, and we can’t do much more splitting and switching?
Well, that’s where the end-game planner comes into play. Since the price barely moves, it can do its work on Saturday, with plenty of time to fix anything that goes wrong, rather than in a last-minute rush.
The planner tries to solve: “given where everyone stands, which way should our top heroes face to give us the best chance of the top three places, whatever the final price S turns out to be?”.
The planner looks at all of our keys, but only changes a small number (at most 16) of our best hero keys.
Without getting too technical, we can think of each key as being a line on a graph, with the vertical axis being score, and the horizontal axis being the unknown final price S.
A key’s score at the end is its equity now plus its position times the move to the final price S. So score = a + q·S: a line whose slope is the position. Longs slope up, shorts slope down, and flat keys are horizontal. The prize goes to the three highest lines at whatever S turns out to be.
An illustration with made-up numbers. Each key is a straight line. Within the likely range for S (shaded), our three lines hold the top three places except at the low end, where the rival’s short line climbs past our long one (red band).
The things the end-game planner can do with the keys to change their lines are:
Cover - we’re just ahead of a rival. Face the same way as the rival, so our line runs roughly parallel to theirs and stays above it whatever S does.
Oppose - we’re just behind a rival. Take the other side: on the same side we could never pass it; on the other side we pass it if S moves our way.
Split - a big group of our own tied heroes holds a place. Move one to three of them to the other side, so the group holds the place whichever way S moves.
Go flat - we’re squeezed between rivals on both sides. A horizontal line: its rank no longer depends on S.
So the planner tries to make sure that, whichever way S goes, our lines are likely to hold as many of the top three places as possible.
The real lines on Friday evening, after the end-game was armed (solid = long, dashed = short). A rival short (red) had crept up behind us, so the planner’s first move was to flip our third-best long to short: on a fall, our three shorts now rise at least as fast as every rival short, so none of them can catch up.
We experimented in back-testing with some variations - should we only allow the end-game logic to change a smaller subset of the keys? Should the end-game start at 20:05 UTC on Friday, or 21:05? (Volatility drops from about 0.26% an hour just after the close to about 0.1%.)
Competitor intelligence
The referee publishes a leaderboard, but only of the top 25 keys, and only shows their scores, which isn’t really sufficient to understand what rivals are up to.
One thing I didn’t do, but probably should have, was to have the agent build and run a copy of the contest referee. This would have allowed perfect tracking of our rivals’ positions and strategies. It didn’t seem to be possible to build it after the fact due to messages expiring?
Luckily TORA built a dashboard (announced in this thread) which did pretty much that, so we could take an occasional snapshot of the top 1000 users’ positions as an extra input into simulations and the real endgame planner.
For the rivals that matter most - the ones near the top - there’s another trick. The referee’s public leaderboard scores everyone at a slightly different price every sweep. A rival’s score is a line (score = a + q·price), so if it hasn’t traded, two or three leaderboards are enough to work out its slope - its position - and so its whole line. That’s how the rival lines in the chart above were drawn.
Closing remarks
It was an interesting challenge, thanks to FLOP Labs for organising it.
I’m not too sure why I won, I didn’t think I would since:
- I was using a fairly modest setup with Claude Code and the same Opus 5.5 model anyone can use
- I don’t think I had any special insight; Opus 5.5 was smart enough to spot the strategy by itself
- I didn’t notice the contest until it had already started, and took a 36 hour outage
- Other competitors seemed to be registering an awful lot of keys - did they know something Claude and I couldn’t think of?
- I had less than 20 hours in total of my time to spend on it
Things that I did that might have helped:
- Downloading historic Hyperliquid price data from the last six months
- Guiding the agent into running lots of back-tests to gather evidence for ideas
- Pushing the agent to try hard to disprove its own ideas
- Gathering intelligence on rival strategies
- Running “rehearsals” using as much of the real code as possible
- Luck - we needed volatility over the 9 days to be not too high and not too low
Looking forward to when flop.finance launches on mainnet!