Uniperp: a Perp DEX encoded entirely inside a Uniswap v4 hook.

Uniswap v4 lets a hook contract intercept the lifecycle of a pool — pool initialization, liquidity adds/removes, and every swap, both before and after the swap math runs, with the option to return a custom delta that the PoolManager applies. We use every one of those hooks to build a perp DEX on top of an honest v4 pool, with the bonding curve + leverage engine living inside the hook itself:

• The pool IS the curve. At create(), the hook seeds the v4 pool with 300 stacked LP positions covering the bonding-curve range (each spanning a W-wide window of cumulative base flow). The hook is the sole LP. The v4 LP primitives literally execute the bonding curve.
• Spot + perps share state. A spot buy and a leveraged open both flow through the same v4 swap; afterSwap updates one curveEthcounter, one TWAP, one set of per-band reserves. No price oracle drift, no divergence between “the AMM” and “the perp engine”.
• Hook-native borrow. Leverage borrows from already-passed bands (base side) or not-yet-touched bands (TOKEN side), via the PoolManager's lock/take/settle primitives — no external lender, no oracle dependency, no funding rate.
• Decimal-generic engine. V, K, W, debt, and sqrtPrice all work in the base's raw units. Same hook code launches against WOKB (18d), USDC (6d), or WBTC (8d) — V/W are calibrated per-base by the admin to hit the same USD-FDV target. The audit suite sweeps 6/8/18-dec bases.
• No graduation / no migration. Conventional launchpads move tokens off their custom AMM onto a DEX once a threshold is hit. Here the token already is on the DEX — the bonding-pool acts as a price floor under the curve and the freely-traded market above it. Leverage works inside the curve's range either way.

The judging axis the hackathon scores Innovation on — “novel mechanism on top of the v4 curve, not a port” — describes exactly this design.

The hook's address carries the v4 hook-permission flag bits encoded in its low 14 bits. Our flag value is 0x2ACC — seven bits set:

Because v4 enforces the flag bits at swap time by reading the hook address, the factory must mine a CREATE2 salt whose hook address has exactly those low bits. The frontend does this in a Web Worker; create() reverts if the salt is wrong. The token salt is mined to the same factory CREATE2 space with an ordering constraint (token > base) so the v4 pool key's currency ordering is fixed at launch.

Hot state during a swap (per-block borrow tally, reentrancy guard) lives in EVM transient storage (TSTORE/TLOAD) — cleared at the end of every tx and gas-free vs. SSTORE. The TWAP rides on v4's built-in observation buffer; the 5-minute window is the liquidation oracle (§6).

The curve is a constant product. Two reserves: a base-asset reserve and a token reserve. Their product is invariant:

E is the cumulative base bought into the curve, realTOKEN is the token still inside the curve, and V is a virtual base reserve that sets the launch price and damps early-buy impact. K = totalSupply × V, so at launch realTOKEN = 1,000,000 tokens (all supply starts in the curve).

The price of one token, in base units, follows from constant-product:

Price grows with the square of curve level. Total supply is fixed at 1,000,000 per launch. V and the band width W are admin-set per base, calibrated so every launch opens at the same USD FDV regardless of which base it's paired against:

target_USD is the opening USD FDV the admin targets at whitelist time (≈ $7,500 across every base, so a launch is the same “size” in USD whether you pair against WOKB or USDC). The audited W/V = 10/7 ratio keeps band geometry self-similar across bases; 10/7 ≈ 1.4286, so with current calibration: a WOKB launch's W ≈ 95.7 WOKB (≈ $10.7K at OKB ≈ $112); a USDC launch's W ≈ 10,696 USDC. The protocol's economic floors (minimum collateral, anti-flash-loan caps, bad-debt thresholds) all derive fromW, so they auto-scale per base without any per-base tuning.

A plain spot buy of ΔE base moves the curve level from E toE + ΔE and pays out the difference in token reserves:

Selling reverses it: feed token back, curve level drops, you receive base. Because price is convex, you always sell into a falling price — the bigger the sale, the worse the average fill. A 1% spot fee, taken in the base asset, applies to every direct spot swap routed through the v4 pool (via the hook's beforeSwap callback). Swaps the protocol performs internally for leverage (the leveraged buy on open, the sell-back on close, the forced sale on a liquidation) bypass this fee via the custom-delta return path (§2) — leverage has its own fee schedule (§9).

Open a position with two inputs: collateral C (in base) and leverage L ∈ {2, 3}. The hook then (long shown; short is the mirror — borrow token, sell for base):

1. Borrows B = C · (L − 1) base from the curve's already-passed bands (§8).
2. Takes a 1% origination fee on the borrow — f = 0.01 · B — routed to the leverage-fee recipient. Effective collateral becomes C′ = C − f.
3. Buys token with C′ + B base via the v4 PoolManager. The hook returns a custom delta so this internal swap does not pay the 1% spot LP fee.
4. Holds H token as your position; you owe debt D = B base to the curve.

Exposure is roughly L × collateral, financed by a one-time origination fee — no funding rate. The position's value at any later price P is just H · P. Safety is tracked by a health ratio:

Ignoring fees: at open H ≈ L·C / P_entry and D = (L−1)·C, so

Higher leverage = thinner buffer between your entry health and the liquidation line.

A position is liquidated the moment health falls to 1.05 (105%):

Solving for the price at which that happens gives a clean result depending only on leverage:

In words — the percentage move from entry that triggers liquidation:

The health check uses a 5-minute TWAP, not instantaneous spot. A single-block price spike — a flash dump, a sandwich — moves spot but barely budges a 5-minute average, so it cannot manufacture liquidations out of healthy positions. Liquidation does not fire-sell — the position is seized whole into a protocol reserve (rate-limited per block), so no forced-sale cascade can spiral.

Partial closes make positions safer. Closing part of a position repays debt first, which pushes the live P_liq away from current price:

Bad debt. In a severe drawdown a liquidation sale can recover less base than the debt owed. The shortfall is a realized loss to the protocol — recorded openly on-chain (a public bad-debt counter) rather than hidden — and is healed over time from the insurance fund and seized-collateral reserve, never from other users' funds.

On close: the hook sells the requested fraction of your token back into the curve (no spot LP fee — internal swap), repays your debt first, credits the surplus minus a 1% close fee. You withdraw what's credited with a separate claim call. Profit on a full close is approximately:

The only frictions are the 1% origination fee at open (on the borrowed amount) and the 1% close fee at exit (on the surplus). Setting profit to zero, the favorable price move just to recover collateral works out to roughly:

About the same at every leverage because round-trip friction is ~1% of the position notional regardless of L. A losing close pays no close fee at all. For an asset that routinely moves tens of percent, this is a small tax — but a position that drifts sideways bleeds it.

The smooth curve is realized as 300 stacked v4 LP positions — bands— each covering a W-wide window of cumulative base flow (band icovers [i·W, (i+1)·W)). Each band is born holding only token; as buyers push the curve level through a band's window, that band converts from token into base. A band the curve level has already moved past is therefore pure base — and that idle base is what leveraged longs borrow. Shorts are the mirror: they borrow token from bands the price has not yet reached, and sell it.

A borrow draws the protocol reserve first, then bands. No band is ever drained more than 40% (long) / 25% (short), and a hard per-blockborrow cap of W base-equivalent (anti-flash-loan) bounds how much can be borrowed in any single block regardless of source. On close, repaid funds go back to bands (refill first, then deepen the curve) — never to the reserve; the reserve is fed only by liquidation seizes.

Borrowing and refilling only ever touch fully-passed (base-only) or fully-ahead (token-only) bands, never the live band straddling the current price — so the curve's price function stays exactly intact and leverage never distorts the published price.

Three fees, each on a different event. No transaction ever pays more than one of them.

A spot trader pays one fee. A leverage trader pays one on the way in (origination on the borrowed amount) and one on the way out (on the surplus, if any). The leveraged buy and the close sell-back are themselves fee-free (custom-delta path, §2). No funding rate.

• Leverage cuts both ways. A 3× long is liquidated by a ~30% drop, a 2× long by ~47.5%; shorts symmetrically on the way up. Liquidation is automatic, on-chain, and final — no margin call to top up.
• You can lose your whole collateral. After liquidation the residual credited back to you is typically near zero; in a deep drawdown, zero.
• Leverage lives inside the curve's range. Longs can only be opened while the price is inside the bonding range. Once a token graduates above the top of the curve it trades freely; the bonding pool re-activates as a price floor (leverage included) if price ever trades back into range.
• Bad debt is possible. Extreme, fast drawdowns can leave a liquidation recovering less base than the debt. The shortfall is tracked openly on-chain and is isolated from user balances, but it is a real risk borne by the pool.
• Thin launch liquidity. A new pool launches with a small base float against a large circulating supply; price can move sharply on modest flow, and the per-block borrow cap bounds (but does not eliminate) per-block leverage activity.
• Smart-contract risk. Like any on-chain protocol, bugs are possible. Use only funds you can afford to lose, and only on the network the app is configured for — signing on the wrong chain can route funds to addresses that don't exist.