BoundV4
pool not liveA supply ratchet enforced at the venue. Every trade through the canonical ETH/BOUND pool burns part of itself: not by convention, not by treasury policy, but because the pool will not settle a swap any other way.
BoundV4 is a fixed-supply ERC-20 on Ethereum, bound at deployment to a Uniswap v4 hook that intercepts every swap against its canonical pool. On the way in, one percent of the tokens a buyer would receive is withheld and destroyed. On the way out, five percent of the ETH a seller would receive is claimed by the hook, spent inside the same transaction on an open-market purchase of the token, and the proceeds of that purchase are destroyed.
The consequence is a token whose supply curve has exactly one admissible direction, and a market in which the cost of leaving is five times the cost of arriving. Neither property is enforced by a policy, a multisig, a keeper bot, or a treasury. Both are enforced by the venue: the swap does not settle unless the burn settles with it.
This document specifies the mechanism, states the invariants precisely enough to be falsified, and renders the realised supply path from on-chain event logs as it accrues.
why token-level burns fail
Every deflationary token of the last cycle implemented the same thing: a tax inside _transfer. Send 100 tokens, 95 arrive, 5 disappear. It is simple to write, and it is structurally broken in three ways that only become visible once the token has to live inside real infrastructure.
First, it breaks accounting everywhere it touches. An AMM that computes a swap output and then receives less than it computed does not degrade gracefully; it reverts, or worse, it silently misprices. Uniswap v4’s settlement layer balances deltas exactly, and a token that quietly delivers less than it was told to deliver leaves the pool unable to close its books. Lending markets, bridges, and aggregators inherit the same problem. In practice, fee-on-transfer tokens end up excluded from exactly the venues that would give them liquidity.
Second, the tax applies to the wrong event. A transfer is not a trade. Moving tokens between your own wallets, funding a multisig, depositing to an exchange, posting collateral: all taxed, none of them the activity the burn was supposed to price. Meanwhile the actual trade is intermediated by a router, so the tax lands on the router’s hop rather than the trader’s intent, and any serious desk routes around it.
Third, and fatally, it is a policy rather than a property. A transfer tax lives behind an owner, a whitelist, an exclusion mapping. There is always an address that pays nothing, and there is almost always an address that can change who that is. The burn is a thing the team is currently choosing to do.
- Logic lives in _transfer, so every movement is taxed, not every trade.
- Breaks AMM delta accounting; excluded from most modern venues.
- Requires exclusion lists, which require an owner, which is a lever.
- Routers and aggregators route around it or refuse to list it.
- Burn rate is a parameter someone can change.
- Logic lives in a v4 hook. It fires on swaps, and only on swaps.
- Settles through the PoolManager's own delta accounting, by design.
- No exclusions, so no owner, so no lever. transfer() is a plain ERC-20.
- Routes through the standard UniversalRouter like any other v4 pool.
- Rates are compile-time constants in the hook's runtime bytecode.
Wallet-to-wallet transfers of BOUND are completely untaxed. The token contract is an unmodified OpenZeppelin ERC-20 with the mint function removed. Allof the protocol’s behaviour lives one layer down, at the venue, which is a place it was not possible to put it until Uniswap v4 shipped.