coldcascade: a 1inch Aqua maker that reads Hyperliquid's order book

TL;DR: For ETHOnline 2026 I built coldcascade, a market maker on 1inch Aqua deployed on HyperEVM mainnet, whose price is computed inside the swap by reading Hyperliquid's own order book through the HyperCore precompiles, so it cannot be arbitraged on a stale price against that book, and which hedges its inventory on the perp from the same contract. It got second place in 1inch's Build an Aqua App prize. The code, the deployed contracts and every measurement are public, and the links are at the end.

The whole mechanism fits in the 54 second animation from below. It is built with Remotion and every frame is computed from the replay's CSV. The prices in it are the real tape of the 10 October 2025 crash, and the book and the forced flow are modelled.

Where the idea came from

I first worked with 1inch's stack a year ago in Unite DeFi, where I extended Fusion+ to ICP. This year they were sponsoring ETHOnline with a prize for apps built on Aqua, their new liquidity layer, where a maker writes its strategy as a small program for a virtual machine called SwapVM and keeps custody of its own funds. When I read the instruction set that the Aqua router uses, I noticed that in the version that is in production there is no instruction that reads anything about the market, so a maker program can commit to a curve, a fee or a schedule, but it cannot react to a price. There is one oracle instruction in the repository, OraclePriceAdjuster, but it is wired only into the generic opcode set and not into Aqua's, it only adjusts the price when that is favourable to the taker, and it has no test in the suite.

In parallel I had been working in the previous months on two papers about liquidation cascades in Hyperliquid's perp markets (arXiv:2607.27070 and arXiv:2608.03616), and Aqua happens to be deployed on HyperEVM, which is the one EVM chain where a contract can read Hyperliquid's order book directly, through precompiles, in the same call. So the project was to write the missing instruction and use that book as its input.

What the research changed before I wrote any code

My first idea was a dramatic one, a maker retreating when a cascade is coming, but the papers do not support it. The first one finds that the usual early warning signals do not work on these crashes, so whatever the maker reacts to has to be measured in the present and not forecast. And when I measured what happens to someone who buys what liquidated traders are forced to sell during the 10 October 2025 crash, the sign was the opposite of what I expected. Across eleven assets, absorbing the heaviest forced flow loses around 110 bps after five minutes, because the cascade is still running, and earns around 130 bps after an hour, when the overshoot has reverted.

I am not presenting that as an established result. It is one event, the eleven assets crashed together, and eight of the eleven are positive at sixty minutes, which is just a suggestion, not a proof. But it was enough to change the design, so the maker would lean into forced flow instead of running from it, and it had to be able to hold that inventory for some minutes.

Coinbase BTC-USD one-minute closes on 10 October 2025, with a strip underneath marking the minutes in which the desk was buying or selling inside the book — Figure 1. The day the project is measured on. BTC falls from around 115,000 to 107,600 in under twenty minutes and comes back. The strip shows the 24 minutes out of 123 in which the desk had one side inside the book, buying on the way down and selling on the rebound.

The chronicle of the ten days

Kickoff and the instruction

The hackathon started on 4 September and I registered in the From Scratch track, so the repository started empty that day. The first decision was how to add the instruction. A custom opcode is the obvious way, but it needs a redeployed router, and then the maker is not on the venue that has the liquidity. SwapVM has an official extension point called Extruction, which calls an external contract through a view function, and a view call is what a precompile read needs. So the maker program ended up being 1inch's own constant product curve followed by my instruction, CoreQuote, running on the official router. CoreQuote reads the best bid and ask, the mark and the oracle price, and the taker receives the minimum of what the curve offers and what the book allows, so the desk never gives a better price than crossing Hyperliquid's own touch would have given in that same call. The second half of the rule is just a flip: when the mark walks more than a threshold away from the oracle, or a liquidation map says that forced flow is coming, the absorbing side moves from outside the touch to inside it, the minimum becomes a maximum, and the desk is the best bid on the screen for whoever is being forced out, still bounded by the book.

A frame of the animation at 21:11:58 UTC. The oracle minus mark gauge reads plus 29 bps, the desk bid is labelled max and sits inside the spread, and the desk ask is still labelled min — Figure 2. The moment the rule flips. The gap between oracle and mark crosses the desk's threshold of 25 bps, and the desk's bid goes from the minimum of curve and book to the maximum, so it steps inside the spread while the ask stays outside.

The first deployments and struggles

On 6 and 7 September I deployed on HyperEVM mainnet, fifteen contracts in total. Most of what I learned in those days was about things the node does that no local test can see. The precompiles have no bytecode, so a fork cannot call them and the tests need mocks etched at those addresses, forge script cannot send a transaction that touches a precompile, and CoreWriter, which is how a contract sends orders to Hyperliquid, only queues the action, so HyperCore can reject it seconds later without failing the EVM transaction. I did not find these documented, and they cost me hours, so I wrote them down in the repository.

The Desk tab of the app, showing Hyperliquid's bid, ask, mark and oracle as the contract reads them, and three desks quoting 20 bps outside that book — Figure 3. The app on mainnet. The top row is the book as CoreQuote reads it in the current block, and the table is what each desk would pay and charge against it, 20 bps outside on both sides, which is each desk's own parameter.

Reframing of the project based on the results

Around the same days I also changed the framing of the project. I had been presenting it as a maker for liquidation cascades, which happen a couple of times a year, and the property that matters in every block is simpler: the price is set during the trade, so it cannot be stale against the book it read. The cascade behaviour is that same property at the moment when the book and the oracle separate.

The clamp and the hedge on mainnet

On 8 September I got the transaction that I think represents the new argument. A taker sold to the desk and was paid 79,539.60 against a Hyperliquid bid of 79,699.00 read in the same call, which is 20.00 bps under the bid and exactly the desk's own parameter, while the desk's curve on its own would have paid 163.6 bps over the bid and given that difference to whoever arrived first. The transaction is 0xfaf1b6c6…dab20, and the taker wallet in it had been created three minutes earlier from an email address, through Privy.

The hedge came the same day. The desk is a contract with its own margin account on HyperCore, and cover() sends an order to the perp when the inventory is off. It is a second transaction and not part of the swap, and because CoreWriter queues, I read every fill back from the chain instead of trusting the receipt. On one of the desks the key that calls cover() is a Privy server wallet whose policy allows that one call on that one desk, and there is a script that asks the live wallet for the other things it should not be able to do (close the desk, transfer its funds, send through CoreWriter, the same call on another chain, one wei of value) and prints each refusal. That desk absorbed a fill and five minutes later hedged it with a short of 0.00015 BTC that I did not sign, the key that did can make no other call.

The Keys tab of the app, with two live short positions, one sent by the owner and one by a policy-held key, and a table of what the live wallet refuses — Figure 4. The two hedges that are open on HyperCore, one that I sent by hand and one that the automation key sent on its own, and under them the output of the script that asks that key for everything else.

Substreams

The last piece was the record. HyperCore's book is not EVM state and the precompiles only return the present. A small contract writes it down once a minute, and a Substreams package decodes the desk's fills and those book snapshots from HyperEVM blocks. A keeper joins every fill to the book 5, 15 and 60 minutes later and posts the markout back on chain. Subgraph Studio does not index this chain, so Substreams on The Graph Market was the only route, and I found that out by reading their network registry.

A scatter of 201 fills over 6.3 days, plotted by their distance in bps from Hyperliquid's touch, with none of them inside a band of plus or minus 20 bps — Figure 5. Every fill the desks signed up to the submission, by its distance from Hyperliquid's touch in the block where it settled. None lands inside the band, which is the bound holding on mainnet. All of these fills are ones I sent myself, so this just shows the clamp; nothing to say about demand.

What I measured

To compare makers I replayed 123 minutes of the 10 October 2025 crash through the official router, with takers that couldn't tell which maker is which. The prices and the taker volume are real Coinbase minute bars and the book is modelled, so the numbers below describe behaviour and not money that exists. All amounts are in USD.

maker	absorbed	edge at 60 min	paid to the arbitrageur	net
the desk	36,878	+1,306	0	+1,306
oracle-pegged, refreshed every minute, same band	3,621	+18	222	-204
1inch's plain constant product curve	5,620	-34	3,558	-3,592
the same curve with a 30 bps fee	10,812	-315	2,713	-3,028

Running total of what an arbitrageur extracted from each of the four makers over the replay. The two constant product curves climb to 3,558 and 2,713, the oracle-pegged maker to 222, and the desk stays at zero — Figure 6. The fourth column of the table, minute by minute. The same search for a profitable round trip ran against the four makers, and against the desk it never found a size that worked.

Two things in this table did not go the way I expected. First of all, the comparison: for most of the first week my mental argument was latency, that an oracle maker is stale, and on this chain that is wrong, because any contract can read HyperCore's oracle in the same call. So I built an oracle-pegged maker with the same band and refreshed it every minute, which is as fast as the tape allows. On ordinary flow it pays nothing to arbitrageurs, the same as the desk, and the two are the same maker. In the cascade it pays 222 and the desk pays 0, and the reason is simply where each one is anchored, because the oracle is an index of other venues' spot that nobody can execute at, the book is a price you can cross, and in a crash the two separate.

A frame of the animation at 21:16:28 UTC, in the middle of the cascade. Forced sellers sweep the bids in red, the desk bid sits among them, and the oracle-pegged maker quotes around the oracle, far above the mark — Figure 7. The same two makers about five minutes after the flip. Oracle and mark are 82 bps apart, the oracle-pegged maker is still quoting around the oracle, where nobody is trading, and the arbitrage counter on the top right has started to run against it and not against the desk.

The second part is about the meaning of absorbing: the desk does not capture a spread when it buys forced flow, it makes a bet that the price reverts, and the 1,306 in the table is that bet paying on one tape with a modelled book. Also the replay has no perp leg, so that number is the markout of unhedged inventory, and a hedge would give up exactly the rebound that it measures. The P&L of a hedged desk is a third measurement that I do not have.

Running total of the edge at 60 minutes for each maker. The desk ends at 1,306 on 36,878 absorbed, just above a dashed line for Hyperliquid's own touch at 1,225 on 57,094, and the other three makers end near or below zero — Figure 8. What the absorbing was worth. The dashed line is what buying at Hyperliquid's own touch would have earned over the same minutes, and it is the line to beat. The desk ends at 354 bps per dollar absorbed against 215 for the touch, on one tape.

The result

I submitted on 13 September, and on the 16th 1inch gave it second place in Build an Aqua App (their announcement).

This is the pitch video, three and a half minutes, and the app is live at coldcascade.vercel.app if you prefer to press the buttons yourself.

Gaps

Every fill on chain 999 so far is one that I sent myself, so nothing here measures demand or profitability. There has not been a cascade since the desks went live, so that behaviour exists on the tape and behind a button on the demo desk, and not on mainnet. I also wrote the same rule as a Uniswap v4 hook, which passes its tests against a mock reader, but today there is no chain that has both v4 and a book that a contract can read, and FEEDBACK.md is what came out of that exercise. So what exists is a working instruction on the official router with its measurements published, and not yet a product with users.

My AI setup

The full version is AI-USAGE.md in the repository, so here I only summarize how I worked. There was a lot of code and interconnected parts, and getting them to work together would usually have taken me more time than it did. This was the first hackathon where the models wrote most of the code, and my work was the mechanism, the plan, reviewing every change and debugging against the live chain. I drove every model from the same harness, Claude Code, including the ones that are not Anthropic's, through a proxy. Claude Opus 5 was the orchestrator for the build, it held the plan across sessions and did most of the implementation, and it also wrote the first version of the app. Claude Fable 5.1 came in at the hard points of the architecture, like the shape of CoreQuote, the desk account and the regime split, and later it worked with me on the animation and audited the whole submission. Kimi K3 refactored the app that Opus had written and led the front end from there.

I also used two models only as reviewers, because I wanted somebody outside the build looking for what was wrong or overstated. GPT-6 Astra Pro did a line by line audit on 7 September, and several corrections to what the README claims came from it, and Grok 4.6 did another one the day after, focused on which sponsor prizes made sense and on checking the numbers. All the reviews were asked to be adversarial.

I did not delegate the mechanism and its parameters, the research behind it, or any of the transactions on chain 999, which I signed with keys that no model has ever held. I also read, made and pushed every commit myself, and the voice in the video is mine.

ETHOnline 2026: a market maker on 1inch Aqua that reads Hyperliquid's book inside the trade