Standby

Demo

About

Institutions increasingly hold productive onchain assets such as tokenized cash-management assets, but their future settlement needs may be denominated in assets such as USDC. When a known liquidity-risk window approaches, their choices can include holding idle settlement balances in advance, relying on issuer redemption, or depending on whatever acceptable secondary-market spot or RFQ liquidity happens to be available when the need materializes. Standby introduces another liquidity instrument: a finite-duration commitment to bounded future secondary-market execution capacity. Instead of reserving settlement assets for a beneficiary, Standby uses qualifying shared AMM liquidity to back the commitment. That liquidity can continue supporting compatible ordinary trading while the commitment is outstanding. The beneficiary therefore gains protocol-enforced access to a bounded amount of future execution capacity without requiring the corresponding assets to sit segregated and idle. Standby is designed to complement, not replace, immediate cash, issuer redemption, RFQ liquidity, and ordinary secondary-market execution. An institution could use committed capacity selectively during identifiable future liquidity-risk windows as one layer of a broader liquidity strategy—reducing dependence on both fully pre-positioned settlement balances and uncommitted future market liquidity. The Uniswap v4 implementation makes this enforceable by tracking Supporting Capacity (S) against Capacity Obligation (O) and preserving the invariant S ≥ O. Compatible ordinary activity continues while sufficient backing remains, but a pool transition that would destroy the backing for an admitted commitment is rejected. The canonical demo proves this distinction end to end: a 50,000 USDC commitment is admitted against 80,000 USDC of supporting capacity; an unrelated trader successfully uses 15,000 USDC from that same shared capacity; a subsequent trade that would reduce supporting capacity below the outstanding obligation is rejected; and the beneficiary ultimately exercises the full 50,000 USDC entitlement through actual Uniswap v4 AMM execution. The broader idea is to give DeFi shared liquidity a new coordination role: not only providing execution now, but supporting enforceable commitments over execution capacity needed later. Standby doesn't reserve liquidity. It protects capacity.

How it's made

Standby is implemented as a Solidity protocol on Uniswap v4. StandbyHook is the enforcement boundary around shared AMM liquidity: it derives supporting capacity from authoritative pool state, tracks outstanding capacity obligations, admits commitments only when they are supportable, and prevents ordinary pool transitions from violating the S ≥ O backing invariant. The exercise path uses an ExerciseRouter and hook-owned causal context so an authorized beneficiary can exercise an outstanding entitlement through actual Uniswap v4 execution. An onchain EligibilityRegistry provides the permissioning predicates used by the demo. The canonical fixture uses MockUSTB and MockUSDC, while execution runs through the real Uniswap v4 PoolManager stack. The contracts and tests are built with Solidity, Foundry, and Anvil. Verification includes unit, integration, fuzz, and stateful invariant testing. The final suite has 590 passing tests, with 99.42% line coverage and 100% function coverage for the Standby protocol core. A minimal frontend provides demo instrumentation by reading authoritative contract, PoolManager, and token state rather than maintaining separate economic state. The canonical demo deterministically reproduces the complete commitment → shared use → protection → fulfillment sequence.