Hooks, with
instructions.
Build custom token markets with real Solidity templates, Uniswap v4, and Robinhood Chain.
Your token. Your hooks.
Hookups turns supported market behaviors into configurable bricks. Compose a recipe, create a fixed-supply token, attach one immutable hook to a native-ETH v4 pool, and seed a creator-owned LP vault.
Your first build.
- Choose a starter. Try the launch kit, burn + LP build, or treasury builder.
- Name your token. Set its name, ticker, and fixed supply. All launch tokens use 18 decimals.
- Configure your hooks. Add bricks and set their parameters. The editor catches fee conflicts, invalid addresses, and output-allocation limits.
- Preview the rules. Check launch times, LP fees, input caps, and output-allocation rates locally.
- Save or export. Named builds and receipts stay in this browser. JSON blueprints can move between devices.
- Review deployment. After platform activation, connect a wallet, choose initial ETH and token liquidity, review the exact charge, approve a bounded allowance, and explicitly confirm deployment.
The rule preview does not simulate chain state, liquidity, price impact, gas, or precise output amounts. Actual transactions are simulated against the configured network before signing.
Open the hook lab ↗Ten bricks. Real contracts.
| Brick | Implemented behavior | Mechanism |
|---|---|---|
| Launch clock | Opens swaps after a fixed delay from pool initialization. No closing switch. | afterInitialize / beforeSwap |
| Fee curve | Linearly reduces LP fees from start to floor after trading opens. | beforeSwap |
| Input guard | Separate token and ETH input caps. Exact-input swaps only. | beforeSwap |
| Swap receipts | Emits an additional event after a swap. A router may be the recorded sender. | afterSwap |
| Fixed LP fee | Sets the immutable static pool fee. Cannot combine with Fee curve. | Pool configuration |
| Donation signals | Emits an event after pool donations. Does not distribute rewards. | afterDonate |
| Burn on buys | Burns a percentage of actual token output on buys, reducing the new token’s totalSupply. No ETH burn on sells. | afterSwap + return delta |
| LP reserve | Collects a percentage of swap output into the launch vault. The owner can add accumulated assets to LP. | afterSwap + return delta |
| Treasury split | Accrues a percentage of swap output. Anyone can trigger payout to the immutable treasury. | afterSwap + return delta |
| LP time lock | Locks removal of the vault’s LP principal and idle reserves. Additions and earned-fee collection remain available. | Vault rule |
Fees and output allocations
100 basis points equal 1%. LP fees are 1–1,000 bps. Burn, LP reserve, and treasury allocations are each positive when selected and total at most 1,000 bps (10%). They are charged on realized output after the swap, including partial fills. LP fees and output allocations are separate.
Burn, LP reserve, treasury, and Input guard recipes reject exact-output swaps. On buys, the output asset is the new token; on sells, it is ETH. Only token output can be burned. Integer rounding can make very small allocations zero.
Adding LP is an explicit action
Initial liquidity is created during deployment. The LP reserve brick collects assets on trades; it does not automatically swap assets or rebalance. Use Onchain → Manage LP → Add reserves to LP to compound suitable ETH and token balances into the full-range position. Adding at the current price can leave one asset partly idle.
The vault owns the position directly in PoolManager; it is not a PositionManager NFT. Its creator is the immutable owner. The lock covers this vault’s principal and idle balances only. Other LP positions, unallocated creator tokens, and collected trading fees are not locked.
Experimental means experimental.
Multi-pool mesh
Sketch two to six markets, a primary-market allocation, and a shared token strategy. No multi-pool creation, routing, funding, or cross-pool accounting is implemented.
Yield balancer
Choose a drift threshold, review interval, and per-pool allocation cap. Requires Multi-pool mesh. No yield oracle, vault strategy, keeper, allocation optimizer, or rebalance transaction is connected.
Both bricks are labeled in the library, canvas, inspector, exported blueprint, and deployment review. They disable execution previews and deployments. The on-chain factory also rejects their module bits. Yield is not forecast or promised.
Many behaviors. One hook.
A v4 PoolKey contains one hook address. This version composes supported behaviors inside one versioned Solidity template with immutable configuration. It binds to one ETH/token pool and restricts initialization to the factory. Callback entry points verify the PoolManager.
Hook address flags occupy the low 14 bits. The browser mines a CREATE2 salt against the factory’s dedicated HookupsHookDeployer address and the exact hook initcode hash. It compares the contract’s required flags with the blueprint before proceeding.
Base guards: beforeInitialize + afterInitialize + beforeSwap Swap receipts: afterSwap Launch kit: 0x30c0 Output fees: add afterSwapReturnDelta (0x0004)
The fee mode and hook address belong to the pool key. This template has no upgrade path or hook parameter setter. Changing a recipe requires a new build and an explicit liquidity migration. A valid recipe is not a security audit.
Burn to build.
Designing and exporting are free. The factory enforces a positive HOOKUPS fee on each successful launch, separate from ETH gas and liquidity. A deployment creates the token, vault, hook, pool, and initial LP in the same transaction as the charge. If any part reverts, the charge and deployment state revert together. Failed transactions can still consume gas.
Two explicit charge mechanisms
- Supply burn: calls burnFrom and verifies the exact payer balance decrease and totalSupply reduction.
- Burn-address transfer: verifies an exact transfer to 0x000000000000000000000000000000000000dEaD. This does not reduce totalSupply and is shown as a transfer in the review.
The actual HOOKUPS contract must be inspected to choose the compatible mechanism. Transfer-tax, rebasing, or no-op burn behavior is not assumed compatible. The platform owner can change future pricing or pause new launches; users supply a maximum fee and deadline. The UI stops if its displayed fee has changed.
The wallet flow requests the exact quoted allowance when a new approval is needed, never an unlimited allowance. Existing sufficient approvals can be reused. Approval alone does not burn tokens. Token burning does not guarantee price appreciation.
From recipe to a funded pool.
| Component | Implemented responsibility |
|---|---|
| Recipe engine | Validation, deterministic composition, callback flags, portable blueprints. |
| Pinned compiler | Solidity 0.8.26, optimizer, viaIR, Cancun; ABI and bytecode artifacts. |
| Factory + hook deployer | Enforced fee, namespaced CREATE2 token/vault creation, mined hook, pool initialization. |
| LP vault | Full-range initial liquidity, reserve additions, fee collection, locked principal withdrawals. |
| Wallet client | Network and runtime-code checks, live fee quote, address mining, bounded approvals, simulation, transaction receipts. |
| Onchain builds | Saved receipts, recovery by transaction hash, verified vault management and treasury payout. |
The initial token/ETH ratio determines the starting price. The factory initializes a new pool and seeds LP within the same transaction at that exact price. Unallocated tokens go to the creator; any liquidity rounding dust stays in the creator’s vault.
Before signing, the review shows the network, platform token, factory, fee mechanism, quoted amount, owner, token allocation, liquidity, lock, predicted addresses, flags, and deadline. An export includes the exact call data. The wallet displays transaction gas; the app simulates and estimates the launch first.
Factory pausing affects new builds only. Existing hooks and vaults have no dependency on the platform’s future pricing, and LP management remains available while the factory is paused.
Turn on paid deployments.
The repository contains the activation script and runbook. No private key belongs in this website or in chat. Use an operator-controlled deployment environment.
- Supply the actual HOOKUPS address, a positive fee, its verified burn mode, and the platform administrator address.
- Install the pinned dependencies, compile, and run the contract tests. Complete a live Robinhood fork check and security review before public use.
- Run the factory script in dry-run mode to verify network and contract code, inspect constructor arguments, and prepare the transaction.
- Explicitly broadcast from a funded operator wallet. The script writes the confirmed factory address and runtime hash with launches still disabled.
- Verify deployed source and constructor bindings, exercise the real wallet flow, then explicitly activate the configuration and publish the site update.
npm ci npm run compile node scripts/compile-contracts.mjs --test npm run test:contracts node --env-file=.env scripts/deploy-factory.mjs # Explicit operator deployment: node --env-file=.env scripts/deploy-factory.mjs --broadcast # After network verification and review: node --env-file=.env scripts/deploy-factory.mjs --activate-existing
See DEPLOYMENT.md in the repository ↗. Compiler manifest and factory ABI / bytecode are downloadable.
The right foundation.
| Chain ID | 4663 / 0x1237 |
| Gas currency | ETH |
| Public RPC | https://rpc.mainnet.chain.robinhood.com |
| PoolManager | 0x8366a39cc670b4001a1121b8f6a443a643e40951 |
| Explorer | Robinhood Chain Blockscout ↗ |
| HOOKUPS / factory / fee | Awaiting actual platform configuration |
These are official documentation references checked October 5, 2026. The authored release has not verified live network bytecode or sent a Robinhood transaction. The operator script requires the expected chain and deployed code before it will proceed.
What works today.
Ten supported bricks, two strictly experimental design bricks, six starter recipes, local rule previews, saves, imports, exports, wallet connection, and network switching. Solidity contracts compile below the deployment code-size limit. Local Anvil tests use the actual Uniswap v4 PoolManager package to exercise paid launches, buy burns, LP and treasury accounting, locks, partial fills, and rollback on failures.
The wallet deployment and LP management client is implemented, but live execution is disabled by the deployment configuration. No platform token address, burn price, or production factory has been invented. No independent audit, live Robinhood fork test, explorer verification, or end-to-end browser wallet test has been completed in this authoring session.
A few good questions.
Can we charge the HOOKUPS burn?
Yes. The implemented factory enforces the fee on successful launches and rolls it back on failure. It needs the real token, fee, and deployed factory before activation.
Is adding LP automatic?
Initial LP is funded during deployment. Trade-based LP reserves accrue automatically; adding those reserves to the position requires the owner’s explicit transaction. No keeper or auto-rebalance service is running.
Can I deploy an experimental recipe?
No. Multi-pool mesh and Yield balancer are design-only and rejected by both the wallet deployment builder and factory.
Are these contracts audited?
No. Local tests are evidence of the paths they exercise, not a substitute for an independent security review and live integration checks.
Will every router support these hooks?
Compatibility is not automatic. Output-allocation templates require exact-input routing with return-delta-aware quotes and minimum-output checks. The local test router is test scaffolding, not a production trading interface.
Does the launch clock prevent bots?
No. It controls opening time. It does not identify traders, prevent MEV, or govern another pool.
The research behind the lab.
Protocol references checked October 5, 2026. Hookups feature descriptions above refer to this repository’s implementation.