Docs
How a description becomes a deployed Uniswap v4 hook.
- 01
Intent
Your description is mapped to one of four registry templates and its parameters. Nothing else can be produced.
- 02
Registry
Each template is fixed Solidity, compiled and tested with Foundry. Permissions are defined by the template, never by you.
- 03
Validation
Parameters are checked against the same caps the contract constructor enforces. Invalid values block deployment.
- 04
Address
Uniswap v4 reads hook permissions from the lowest 14 bits of the hook address. HookForge mines a CREATE2 salt in your browser until the address matches the mask.
- 05
Simulation
The deployment is executed with eth_call against Robinhood Chain before your wallet is asked to sign.
- 06
Wallet
Your wallet sends the transaction to the canonical CREATE2 deployer. HookForge never holds keys and has no deploy endpoint.
Canonical contracts
- Network
- Robinhood Chain (4663)
- PoolManager
- 0x8366a39cc670b4001a1121b8f6a443a643e40951
- PositionManager
- 0x58daec3116aae6d93017baaea7749052e8a04fa7
- CREATE2 deployer
- 0x4e59b44847b379578588920cA78FbF26c0B4956C
Risk
The templates are tested but have not received an independent security audit. Hooks are immutable once deployed. Hooks see the router that calls the pool, not the end trader, so per-wallet rules cannot be enforced reliably and are not offered.