# ReserveStable

> A pegged-pair pool that pays arbitrageurs to rebalance it, out of a fund it filled while going wrong.

A production Uniswap v4 hook. Source: https://github.com/nirholas/reserve-stable. Part of the HookForge catalogue: https://hookforge.pages.dev

## How it works
Every stable pool in production prices with a curve that is flat near parity and steep away from it, and every one of them shares a defect: the only force restoring balance is the price the curve happens to quote. When one side runs low, the pool makes it expensive to take more, and then it waits. Nothing pays anybody to bring the missing side back. Arbitrage does it eventually, if an external venue happens to make it worth doing, and if it does not, the pool sits lopsided with its deep side useless and its shallow side unusable. This pool prices at parity and adjusts with a signed spread rather than a curve. A trade that takes from the scarce side pays a spread that grows as that side gets scarcer, from `baseSpreadBps` up to `maxSpreadBps`. That much is ordinary. The part that is not: everything charged above the base rate goes into an explicit stability fund rather than to the providers, and a trade that takes from the *abundant* side is paid a rebate out of that fund. Restoring the balance is not merely cheaper than breaking it, it is profitable, and it is profitable in exact proportion to how badly the pool needs it. The fund is what makes this safe rather than a subsidy with no source. It only ever grows from spread charged above the base rate, and no rebate can exceed it, so across any sequence of trades the pool pays out strictly less than it took in for this purpose. Providers cannot be made worse off than they would have been in the same pool charging a flat `baseSpreadBps` and nothing else, which is a property, not an aspiration: it follows from the fund being a separate balance that a rebate can only draw down. The round trip does not pay either. `maxRebateBps` is capped at `maxSpreadBps - baseSpreadBps` at construction, so breaking the balance and restoring it costs the base spread twice and recovers at most what breaking it paid in. The fund is also empty when the pool is balanced, which is exactly when a round-tripper would want to start. Underneath both of those sits a floor: no swap may leave either side holding less than `minSideBps` of the pool. That is the band. A pegged pool that will sell the last unit of one side at any price is a pool that can be emptied, and no spread schedule fixes that, because the last unit is worth more than any finite fee. Reserves are normalized to eighteen decimals from the units given at construction, so a six-decimal stablecoin and an eighteen-decimal one are compared correctly rather than off by a factor of a trillion.

## Prior art
Curve's StableSwap and the v4 hooks that reimplement it quote a flat-then-steep curve. Frax's AMOs, Angle's transmuter and Reflexer's redemption rate move a peg by minting or by changing a target, all with a governed controller. Dynamic-fee hooks price imbalance in one direction only, because a fee cannot be negative. A v4 pool that pays a bounded negative spread to whoever restores its balance, funded solely by the surcharge it collected while losing that balance, and provably unable to pay out more than it took in, is the contribution here.

## Where it does not help
Only sound for a genuinely pegged pair. The fund is denominated in normalized units and treats one side as interchangeable with the other, which is true while the peg holds and false the moment it does not: against an asset that has actually broken, this pool will pay a rebate for taking the good side and call it rebalancing. Pair it with a depeg guard rather than trusting it alone. The pricing is also constant-sum, so it never quotes anything but parity plus a spread, and it does not move the v4 pool price at all, which means it publishes no oracle a downstream contract can read.

## Facts
Slug: reserve-stable
Contract: ReserveStableHook
Callbacks: beforeSwapReturnsDelta, beforeSwap, beforeRemoveLiquidity, beforeAddLiquidity, beforeInitialize
Parameters: none
Dynamic fee required: no

## Caveats
- Unaudited.
- A deployment with status "deterministic" is a mined CREATE2 address with no code at it yet. Never present one as live.