chapters· Build on top
26 · Build & manage

Build launchers & apps

Launchpads, lockers, vaults and DAOs that compose on the hook's roles and one-tx launch.

The hook is public infrastructure: no fee, no owner, no permission to ask. Launchers, lockers, vaults and DAOs compose on three primitives — the one-transaction launch, the two surrenderable roles, and the recipient hooks.

Pattern 1 — a token launcher

A launchpad contract deploys the token and calls launchPool in the same transaction: pool, pot and seeded LP program, live from block one. The launcher itself becomes the pot admin and the program owner — which means your launcher decides the trust story:

a minimal launcher
function launch(bytes32 salt, …) external payable { token = new Token{salt: salt}(…); // pool + pot + seeded program, atomically: HOOK.launchPool{value: msg.value}( key(token), sqrtP, address(token), address(0), // buy-and-burn 0, 0, seedLiquidity, address(0), // owner 0x0: locked + frozen + public from birth config ); }

With owner = address(0) the whole thing is trustless from birth — the exact "liquidity can never leave" guarantee launchpads advertise, enforced by the hook rather than by your code.

Pattern 2 — a locker or vesting vault

A locker doesn't need custom integration: it simply becomes the program owner via transferProgramOwnership. The locker's own release schedule then gates removeProgramLiquidity — a timelock, a vesting curve, a DAO vote, whatever it implements. The operator role can stay with the project (tunable fees under a locked LP) or be frozen separately.

Pattern 3 — a rewards or treasury sink

Point value at your system: make your staking vault the pot's recipient (bought main streams to stakers), or a program's mainRecipient / secondaryRecipient (a share of LP fees funds the treasury). Implement nothing; receive pushes; claim as fallback if you ever refuse one.

Pattern 4 — bots & routing

surfaceopportunity
quotePump / quoteShieldrouters can price the machine into their paths — a shielded sell has better effective depth than the raw pool
harvest(key)when publicHarvest is on, harvest-calling is a public good anyone can run (the auto-trigger already fires on swaps)
flushDirect(poolId)permissionless retry of parked deliveries — free karma for keepers

What you can rely on

stability guarantees

The hook is immutable and un-upgradable: the ABI you integrate today is the ABI forever. The address is identical on all 23 networks and will be identical on future ones. The licence explicitly authorizes building on the deployed hook — pools, donations, integrations, interfaces, tokens adopting it. Deploying your own copy is what it restricts.

FAQ

Can I build a launchpad on GlueHook?+

Yes, explicitly — launchPool was designed for it: your launcher composes token creation with a one-transaction hooked-pool launch, and your product holds whatever roles your policy needs.

How does a locker compose with the roles?+

The locker contract holds the owner role and enforces its own timelock before ever calling removeLiquidity — the hook stays a neutral primitive; the locker is the policy.

Can a vault automate harvest and claims?+

Yes — a keeper-style vault can hold the owner role (or act after a surrender made harvest public), call harvest(key) on its schedule, and claim() its owed balances.

Do I need permission or an API key?+

No — everything is on-chain and permissionless: public functions, free views, deterministic addresses. The docs and the verified source are the whole integration surface.

Is there a reference UI I can fork?+

This site itself — the app is a DB-less, indexer-less interface that any team can fork and re-skin; pools are discovered from public logs and token lists.