Overview

hood.dev is a token launchpad and trading terminal built natively for Robinhood Chain. A creator deploys a token, its market, and its permanently-locked liquidity in a single transaction; a trader buys that token — or anything else on the chain — through one contract that routes across every venue. Everything below is live on mainnet.

#The core idea: the pool is the curve

Most launchpads run a bonding-curve contract, accumulate reserves, and then “graduate” the token by migrating those reserves into a DEX pool. That migration is the single most fragile moment in a token’s life — it needs a trigger, it can be front-run, and it is where a lot of pads have lost funds.

hood.dev has no curve contract and no graduation. At launch the entire supply is minted into one single-sided concentrated-liquidity position, and the pool is initialised at exactly that position’s lower boundary. There is nothing but tokens in the pool, so the first buyer walks the price up the range exactly like a bonding curve would — except the “curve” is a real Uniswap V3 pool from block one. It is already listed. It is already routable. There is nothing left to migrate.

   creator ──▶ HoodLauncher.launch{value: fee + devBuy}(params)
                       │
     ┌─────────────────┼──────────────────────┬───────────────────────┐
     ▼                 ▼                      ▼                       ▼
 HoodToken       V3 pool @ 1% tier      single-sided mint        FeeLocker
 fixed supply    initialised at the     100% of supply as        holds the LP
 no mint/pause   position boundary      ONE position            NFT forever
                                              │                       ▲
                                              └───────────────────────┘

              anyone, any time:  FeeLocker.collect(positionId)
                                       │
                                 V3FeeReceiver
                        token side ────┴──── WETH side (70/30)
                             │                    │
                     token fee policy      creator fee policy
                   burn · vest · stake     buy-burn · stake

#What you can do

#How the contracts are built

Four rules run through the whole system. They are the reason the surface area an admin can touch is as small as it is — see Security model for the full accounting.

• What a token binds to at launch is permanent. Its pool, its locked position, its fee split, its fee-policy modules and its sniper-guard constants are fixed the moment launch() returns. Later protocol upgrades apply to future launches only — nobody can re-point the machinery under a live token.
• Registries are append-only. Launch venues and trade adapters can be added and paused, never re-pointed or removed. A route that worked yesterday carries exactly the trust assumptions it had when it was registered.
• Value moves on pull, not trust. Fee collection, buybacks, vesting claims and reward top-ups are permissionless. Where a push could fail — a blocklisted recipient, a reverting policy — there is a credited fallback, so one bad address can never brick fee collection for everyone else.
• Approvals stay put. You approve the trade manager and nothing else. Adapters never see an allowance and never hold funds between transactions, which is what lets new venues ship without asking anyone to re-approve.

#Where to go next

• Brand new here? Funding gets money onto the chain and Wallets & keys explains what is holding it.
• Launching something? Start with How a launch works, then Fee policies.
• Integrating? Contract addresses, Interfaces and Data & indexing are the three pages you need.
• Just want the numbers? Fees lists every one of them in a single table.