HookForge

Docs

On-chain metadata

The problem

A hook is an address in a PoolKey. Nothing about that address tells an indexer, a wallet, a router or an agent what the pool actually does. The fourteen permission bits say where the hook intervenes but nothing about what it does there: beforeSwap is equally consistent with a fee discount and a total block on trading.

So hook discovery today is a curated list maintained by hand, and everything not on that list is an unknown address that tooling either ignores or renders as a warning.

The interface

Four view functions, all answerable from constants, costing no storage and about 200 gas to query. Every HookForge hook implements it, and it is deliberately small enough that any hook can. 

interface IHookMetadata {
    function hookName() external view returns (string memory);
    function hookVersion() external view returns (string memory);
    function specURI() external view returns (string memory);
    function hookTags() external view returns (string[] memory);
}

Ask any HookForge address what it is:

cast call $HOOK "hookName()(string)"
cast call $HOOK "hookTags()(string[])"
cast call $HOOK "specURI()(string)"

It is discoverable through ERC-165, so a caller can ask whether an arbitrary hook supports it before calling.

The manifest

specURI() points at a machine-readable manifest carrying what does not belong on-chain: the full description, the parameter list with units, the prior art, the limitation, the errors, the ABI and the deployments. Manifests follow one schema and are served at stable URLs: 

https://hookforge.pages.dev/schema/hooks/<slug>.json

Each is generated from the contract, so a manifest cannot describe a hook as something it is not.

Adopting it

IHookMetadata is MIT licensed and has no dependency on anything else here. Copy the interface, return four constants, and point specURI anywhere you like. It costs nothing and it makes your hook legible to every tool that learns to ask.

Hooks in this catalogue are also submitted to Uniswap's hooklist, which remains the right place for a curated allowlist. The two are complements: a list says which hooks are blessed, self-description says what an unlisted hook claims to be.