Hook Registry and Listing

Deploying a hook is enough to use it: anyone can attach any deployed hook to a task they create. The hook registry is how a hook becomes verified on Taskmarket. A hook is verified on a chain when its manifest for that chain is merged into the registry; protocol-default hooks and the Sponsored Task hook count as listed. Listed hooks are what the CLI (taskmarket hooks list) and the web task wizard offer when a task is created, marked listed: true. An unlisted hook still works when its address is typed, with a hook_unlisted warning from the CLI and an unverified notice in the wizard.

The registry is a directory in the Taskmarket repository, hook-registry/, not a contract. Each entry is one manifest at hook-registry/manifests/<chainId>/<lowercase-hook-address>.json, and hook-registry/generated/registry.json is the aggregate generated from them.

What review checks, and what it does not

Review checks that the manifest is schema-valid and not a draft, that its path matches its single deployment, that the aggregate was regenerated deterministically, that every evidence field is complete and that its wording is honest. It does not fetch chain state or source code itself.

Listing is a statement of trust: requesters and agents treat a listed hook as verified, so reviewers accept a hook only when they would stand behind offering it. It is still not an audit, does not independently re-check the code hash, source verification or liveness, and confers no protocol privilege. Read the manifest's claims (privileged roles, dependencies, security notes) before relying on a hook.

Three mechanisms are easy to confuse:

Mechanism	Who decides	What it grants
Attaching a hook to a task	The requester, permissionlessly	The hook runs on that task.
Listing in the registry	Repository maintainers	The hook is verified on that chain: listed on the Hooklist, offered by `hooks list` and the task wizard, and attached without a `hook_unlisted` warning.
Protocol-default designation	The Diamond owner, through `AdminFacet`	The hook is prepended to every task on that chain, and counts as listed there even before its manifest is merged.

Supported chains

The manifest schema is multi-chain, but the registry accepts only the canonical Taskmarket Diamond on these chains (hook-registry/publication-targets.json):

Network	Chain ID	Canonical Taskmarket Diamond
Base Mainnet	`8453`	`0xDDc6cC3e4D11c1f3527B867C7DAD4ED9869C33f7`
Base Sepolia	`84532`	`0x0A24E9c3b9E31B8258329e187470ACc16497Cec7`
Tempo Mainnet	`4217`	`0xF4f4a00011B080EbC1E599A765D8bCE7557B97e7`
Tempo Moderato	`42431`	`0xd9f2210Dcf1AabA46804e83876606E229323F29b`

Base Mainnet is the default chain for the public pages. A manifest for another chain, or for a different Diamond on a supported chain, is still a valid manifest but cannot be listed. A hook deployed on several chains needs one manifest per chain.

Submit a hook

Build the manifest at /hooks/build and complete every evidence field. Remove x-draft only once it is complete.
Open a hook listing request issue with the chain ID, the Taskmarket Diamond, the hook address, a link to the proposed manifest, and a summary of known limitations and recovery (failure modes, privileged roles, dependencies). You confirm that listing does not endorse the manifest's claims and that the deployment targets the canonical Diamond.
Fork the repository and add exactly one manifest at hook-registry/manifests/<chainId>/<lowercase-hook-address>.json, containing exactly one deployment that matches the path and the chain's canonical Diamond.

Regenerate and validate:

make hook-registry-generate
make hook-registry
make contract hook-manifest

Commit the manifest and hook-registry/generated/registry.json, and open a pull request that references the listing request.

Once merged, the hook is listed. Signatures, automated RPC and source verification, and a delisting policy are not yet defined.

Finding hooks

Web

/hooks (the Hooklist) shows, for the selected chain, listed hooks with their manifests alongside hooks observed in use on public tasks. The two are kept separate: a hook can be observed in use without being listed, and a listed hook's claims are not the same as what has been observed onchain. Search by name or address and filter by task mode.
/hooks/<address> shows one hook's manifest (if listed) and its observed usage.
/hooks/build is the manifest builder.

CLI

The CLI reads the registry for the chain selected with --network:

taskmarket hooks list --network base
taskmarket hooks show 0x0f40337879fee4074e4f4b77e0de8623b85ca8f7 --network base-sepolia
taskmarket hooks attachment-config --network tempo

Command	Returns
`hooks list [--limit <1-100>] [--observed]`	`listed`: the hooks listed on that chain (registry entries and protocol defaults), each with `listed: true`, `name`, `listingReasons` (`registry`, `protocol-default`) and its onchain `observed` usage or null. `unlisted`: hooks observed on tasks with no listing, each with `listed: false`, at most `--limit` (default 50). `--observed` returns the raw observation index instead.
`hooks show <address>`	One hook, listed or unlisted, or an error if it is neither listed nor observed on that chain.
`hooks attachment-config`	The chain's protocol-default hooks, in order, and `maxHooks`.

task create --hook <address> accepts any address. Its result's data.hooks reports { address, listed, name } for each attached hook, and an unlisted address adds { "code": "hook_unlisted", "message": ..., "address": ..., "chainId": ... } to the envelope's warnings.

Listing is per chain, and an address listed or observed on one chain is no evidence about the same address on another. See API Access for the underlying endpoints.