Fren ⨀

Uniswap V4 Hooks have opened up a new world for traders, gamers, and builders. Taking a once fairly fixed trading experience and making fees, liquidity, and pool behavior customizable on chain. We are still only scratching the surface of what people can build. That freedom also creates a difficult problem. Every new idea can become another pool, another place to attract liquidity, and another trading experience that users and aggregators have to understand. A pool might have dynamic fees, but what happens when its creators want to add limit orders? Or long-term trading? Or something entirely new that gets built six months later? In V4, a pool’s hook is fixed when the pool is created. Unless that hook was designed to support new functionality, changing it means creating a different pool and convincing liquidity to move again. Attract liquidity, make it sticky, start over. A problem that has long plagued this space. Sazare will build the most expressive and customizable foundation for pools that want to keep growing alongside the things being built around them. To do that, we are building two things: The Kernel Hook and The Hook Catalog. The Kernel Hook lets pool creators assemble their own pool behavior from compatible hook extensions. They choose what to install, configure how it works, activate or deactivate it, and decide the order in which those extensions operate. That configuration can begin before the pool ever opens. Later, extensions designed to support existing pools can be added without creating a new pool or asking everyone to move their liquidity. This creates room for combinations that would otherwise need their own dedicated hook. Dynamic fees alongside limit orders. Long-term trading alongside launch protections. Custom trading mechanisms, volatility strategies, or games built around how a pool behaves. The Hook Catalog is the curated set of extensions that Kernel pools can choose from. It will include things built by Sazare, third-party contributions, hackathon experiments, and whatever other amazing ideas people bring into this space. Some will be serious trading infrastructure. Others will be gamified, wacky, or entirely new types of meta-AMMs. Sazare controls what can enter the catalog, while pool controllers decide what their own pools use. Changing a catalog listing does not give us the ability to remotely remove an extension from someone else’s pool or rewrite its installed implementation. There are also rules around how extensions operate together. Pools can limit how much work they perform, require essential behavior to succeed, and allow explicitly optional behavior to be skipped when it fails. Removal checks for remaining funds, positions, and obligations reported by the extension. The bigger ambition is interconnectedness. Kernel extensions can coordinate trades and liquidity actions across participating pools within the same transaction, under defined execution rules. That gives us a foundation for meta-protocols: systems whose behavior spans multiple pools, with different extensions contributing to a larger trading experience. Every compatible extension added to the catalog gives eligible pools another building block. More participating pools create more places for those building blocks to operate and interact. Humans, teams, and agents could use the same foundation to assemble and manage these systems. The surface of hooks is still being scratched. Pool controllers should be able to improve alongside it, and builders should be able to create things that grow together.