Why five blocks, and why not six

Every week someone asks for a sixth block. A vesting gate, a whitelist window, a buyback vault. Most of the ideas are good, which is exactly the problem: a hook system grows the way a kitchen drawer grows, one reasonable addition at a time, until nobody can say what is in there.

The five blocks that shipped are the ones that survived two filters. First, the behavior has to live inside the swap itself, on the pool's own callbacks. Anything that needs a keeper, a schedule, or an oracle imports a liveness assumption we cannot audit once and forget. Second, the behavior has to be parameterizable without becoming programmable. A guard window length is a parameter. A custom curve formula is a program, and programs are where launch-time trust goes to die.

The 2025 Cork exploit is the cautionary tale we keep taped to the wall: eleven million dollars out the door through bespoke hook callbacks that no shared audit had ever seen. Our answer is structural. Launches cannot write logic here. They can only tune what the registry has already had audited, which means the thousandth launch is exactly as reviewed as the first.

A sixth block will happen eventually. It will happen the way the leverage factory happened: contracts first, receipts pinned, a labeled design published for review, and a bond posted by whoever proposes it. The drawer stays organized because the bar for entry is a bond, not a pull request.