Open akarys92 opened 1 month ago
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?
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
Takeaway -
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.
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:
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:
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:
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!