On Chain Hook Registry

[akarys92]

Component

General design optimization (improving efficiency, cleanliness, or developer experience)

Describe the suggested feature and problem it solves.

Problem

Uniswap V4 supports a new concept called a hook where any developer can create an arbitrary contract that does some functionality in the swap process. This poses a problem for integrators with Uniswap V4 in both routing and interfaces.

• Routers need to be able to find all the hooks that a pool could use, understand what they do and if they are safe and then finally decided if they want to route through those pools.
• Interfaces need some way to be able to display metadata about hooks to their users so they can understand if they are safe to LP into.

Approach

To address these problems I propose HookRegistry, an ERC-721 based registry for managing hook contracts used in Uniswap V4.

HookRegistry allows the deployer of a hook contract to mint an NFT with metadata about the hook stored. Additionally, it enables auditors to sign these NFTs with a known key they publish, providing a mechanism for integrators to verify audits on chain and display metadata to users off-chain. An example of the recommended metadata structure would be:

struct HookMetadata {
        string name;
        string description;
        string contact;
        string docsLink;
        address[] auditors;
    }

Ideally this protocol would be deployed as part of the v4-periphery so that it sits on every chain Uniswap V4 is deployed to.

Describe the desired implementation.

The Hook Registry should be an ERC-721 compatible contract that supports the following functionality:

• Minting Hook NFTs Allows the deployer of a hook to mint an NFT containing structured metadata about their hook. If the minter does not match the deployment address of the hook, they will not be able to mint.
• Audit Signing Auditors are able to use a known key to sign hook NFTs confirming that they have audited them.
• Update Metadata The creator of the original NFT (who is by definition the hook deployer) is the sole party able to update the metadata for a given hook.

Describe alternatives.

Off Chain Approach

Similar to TokenLists, we could maintain an off chain standard for publishing hook metadata and audit information like the following:

[
	{
		metadata: {
			name: (String) A display name for the hook
			address: (String) Address of the hook
			chainId: (Int) The chain the hook is deployed on.
			description: (String) User description of hook. 
			contact: (String) Contact for developer. 
			docs: (String) Docs for the hook.
		}, 
		audits: [
			{
				auditor: (String) Name of auditor, 
				link: (String) Link to the audit, 
				publicKey: (String) Auditors public key,
				signature: (String) Hook deployment address signed by the known key of the auditor.
			} 
		]
		signature: (String) Metadata object signed with the same private key that deployed the contact at metadata.address
	}, 
	...
]

We could then provide a set of tools that allows hook deployers and auditors to sign metadata just as they would on chain as well as tools that allow integrators to verify those signatures.

Although this would be a lighter weight implementation, it would require ongoing management from teams like Uniswap who would need to host these lists in perpetuity.

Additional context.

Open to other approaches!

[linear]

PROTO-349 On Chain Hook Registry

[snreynolds]

Just jotting down an alternative....

Maybe we can publish a IHooksMetadata interface that exposes some of these properties natively on the Hook contract itself?

something like:

interface IHooksMetadata is IHooks {


          name()

          description()

          docs()

          audits()


}

Then an offchain hooks list can query these fields on the actual hook addresses should they be implemented?

[akarys92]

Brief prototype of the ERC721 implementation, although I may be leaning towards @snreynolds idea now.

https://github.com/akarys92/v4-periphery/blob/HookRegistry/src/base/HookRegistry.sol

[marktoda]

Takeaway -

• Create IHooksMetadata interface
• Create HooksList standard
• hooks lists can pull info from IHooksMetadata, maybe index a standard one that includes all deployed hooks based on poolcreated events

[PoeAudits]

What about including some kind of digital fingerprint for the hook contract, like a bytes32 variable containing the hash of the deployed bytecode. Therefore any changes to the bytecode, or similar/deceptive looking hook contracts will generate unique values.