How did you integrate our partners, if any?
We built a keeper-free depeg circuit-breaker with Reactive Network. A Reactive Smart Contract on Reactive Lasna (OrbitalDepegReactive) subscribes to a Chainlink price feed's AnswerUpdated event for one of the pool's stablecoins; when the reported price leaves the peg band, it emits a cross-chain Callback to Unichain Sepolia. There the Reactive callback proxy invokes our OrbitalDepegCallback contract, which is registered as the hook's guardian and calls OrbitalHook.guardianPause() pausing the pool the instant an external oracle reports a depeg, faster than any human or keeper. The breaker can only pause (a fail-safe action); resuming the pool stays owner-only so a human reviews first. Unichain Sepolia (1301) is a supported Reactive destination, so the hook is the callback target directly and reactive-lib stays out of the audited core
What are the key links to share? (Ex. demo video, GitHub, deck)
Github: https://github.com/Oxkai/Orbital.Hook
Slides: https://docs.google.com/presentation/d/1LNTvnNO2X7vZTLA7QAB-9TJrX7mUNy1U/edit?usp=sharing&ouid=105214943995009815133&rtpof=true&sd=true
Project Link: https://orbital-hook.vercel.app
Demo Video: https://vimeo.com/1200669208?share=copy&fl=sv&fe=ci
Problem / Background: What inspired the idea? What problems are you solving?
Stablecoin LPs look safe until a peg breaks. In a flat stableswap like Curve, a depeg drains the pool into the broken coin and every LP is left holding the bag the classic stable-LP impermanent loss. These pools are also capital-inefficient (liquidity is spread across prices that never trade) and practically capped at two or three assets, so a multi-stable pool fragments into many shallow pairs.
We were inspired by Paradigm's Orbital paper, which generalizes the stableswap onto an N-dimensional sphere. That geometry lets one pool hold many stablecoins at once, lets each LP concentrate liquidity tightly around the peg for far higher capital efficiency, and crucially isolates a single depegged coin instead of letting it poison the whole pool. We built that as a production Uniswap v4 hook so it plugs into real routing and flash accounting, turning the paper into something an LP can actually use.
Impact: What makes this project unique? What impact will this make?
Orbital is, to our knowledge, the first N-asset concentrated stableswap shipped as a live Uniswap v4 hook it takes Paradigm's Orbital paper from theory to a working on-chain pool. Its core features:
- One pool, many stablecoins: all the pairs of a multi-stable basket share a single hook and one reserve vector on the sphere, instead of fragmenting into shallow two-asset pools.
- Virtual reserves for deep liquidity: each tick uses virtual reserves to amplify depth right at the peg, so the price barely moves on size - the pool quotes like it holds far more capital than is actually deposited, and the tighter an LP concentrates, the deeper that liquidity gets.
- Torus consolidation, O(1) swaps: interior and boundary ticks are consolidated into a single torus invariant, so a swap touches the whole book at once and stays O(1) no matter how many assets or ticks the pool has (the engine tracks only the running sums of reserves).
- Automatic depeg isolation: when a coin breaks peg, its ticks flip to their boundary and the bad coin is fenced off - capping the tail impermanent loss that wrecks Curve-style LPs and directly answering the Hookathon's "Impermanent Loss" theme.
- Native v4, no custom router: the basket is exposed as the N(N-1)/2 token pairs, all bound to the same hook, so it routes through the standard Universal Router and PoolManager like any v4 pool - no bespoke router required. Tokens never leave the PoolManager; the hook settles swaps entirely in ERC-6909 claim tokens via flash accounting, so it is non-custodial and cheaper to trade against.
The impact is a stablecoin venue where deep multi-coin liquidity, high capital efficiency, and depeg protection coexist - making LPing in stables meaningfully safer and more profitable, and giving the v4 ecosystem a reusable higher-dimensional AMM primitive.
Challenges: What was challenging about building this project?
The hardest part was turning the Orbital paper's continuous geometry into exact, gas-bounded Solidity:
- Sphere/torus math on-chain: the swap requires solving the spherical invariant with a Newton iteration in fixed-point (WAD), keeping the result within ~1 ppm of the true root while never overflowing or dividing by zero at the tick boundaries. Reproducing the torus consolidation (interior + boundary ticks as one invariant) so a swap stays O(1) took the most iteration.
- Fitting N assets into v4's two-token model: a v4 pool is a pair, but Orbital is one basket. We had to expose the basket as N(N-1)/2 pairs that all share a single hook and one reserve vector, intercept every swap in beforeSwap, return the right BeforeSwapDelta, and settle through the PoolManager in ERC-6909 claim tokens via flash accounting — without the hook ever custodying tokens.
- Tick crossings and depeg isolation: detecting when a swap pushes a tick from interior to boundary, accounting for the crossing mid-swap, and fencing off a depegged coin cleanly were the most correctness-sensitive paths and the source of the trickiest edge cases.
- Gas: a naive solver recomputed sqrt(n)·WAD ~30 times per swap. Caching it as an immutable plus a bit-shift-seeded sqrt cut roughly 83% off solver gas (solveSwap ~393k -> ~65k), and we bounded the tick-crossing scan to stop a dust-tick griefing/DoS vector.
- Frontend faithfulness: quoting accurately through the V4Quoter, building an interactive 3-token sphere simulation that shows ticks/virtual reserves/prices honestly, and serving a fast transaction history without running a dedicated indexer.