---
name: hyperpad
version: 1.0.0
description: >
  Operate the HyperPad token launchpad on HyperEVM on a user's behalf — discover
  sales, participate (buy), claim vested tokens, refund failed sales, and (for
  projects) launch a token. Read this before taking any on-chain action.
chain:
  name: HyperEVM
  chainId: 999
  rpcUrl: https://rpc.hyperliquid.xyz/evm
  nativeSymbol: HYPE
  explorer: https://hyperevmscan.io
entrypoints:
  factory: "0x0F3e6CBc6a16E84a91CE368Ee35ADc294E2048D8"
safety:
  - Never spend more than the user's stated budget. Treat the budget as a hard ceiling.
  - Simulate / eth_call every state-changing tx before sending; abort on revert.
  - Re-read sale state immediately before acting — sales change state with time and blocks.
  - Confirm token & sale addresses against the factory's SaleCreated events; never trust a link.
---

# HyperPad agent skill

You are acting for a busy user who has delegated launchpad tasks to you. Your job is to
do exactly what they asked, safely, and report back with verifiable on-chain results
(tx hashes, amounts, addresses). When in doubt, prefer **read-only** verification and ask
the user before spending funds beyond an explicit budget.

## What HyperPad is (one paragraph)

A token launchpad. Each launch is its own `Sale` contract (an EIP-1167 clone). Users buy with a
quote asset (native HYPE or an ERC20) until a hard cap; if a soft cap is met the sale settles, seeds
**locked** liquidity on HyperSwap V3, and opens **vested** claims paid from a segregated `ClaimVault`;
if it fails, buyers refund in full. Token supply is fixed (no minting). Pricing is **FCFS** and either
a **fixed price** (`tokensPerQuoteUnit`) or **USD-denominated via an oracle** (`ORACLE_USD`). A sale is
**single-phase** by default or **multi-phase** (e.g. a discounted whitelisted private round → public),
FCFS within each phase. See `reference/launchpad-spec.md` for the full data model.

## The four things a user will ask you to do

1. **Discover / monitor** — "find the X sale", "tell me when it opens", "is it legit?".
   → read-only. Use `skills/discover.md`.
2. **Participate (buy)** — "put 500 USDC into sale X at open", "buy the dip to my max".
   → spends funds. Use `skills/participate.md`. **Respect the budget.**
3. **Manage position** — "claim my tokens when vested", "refund me if it failed".
   → Use `skills/claim-refund.md`.
4. **Launch (project side)** — "launch my token with these terms".
   → spends funds + commits tokenomics. Use `skills/launch.md`. Confirm every parameter.

## Golden rules (apply to every action)

- **Decimals are explicit, never assumed.** Quote amounts use the *quote token's* decimals
  (`quoteDecimalScale` in `getSaleData`, e.g. 1e6 for USDC, 1e18 for native). Token amounts use the
  *sale token's* decimals. The buy `amount` is ALWAYS in the quote token.
- **Two pricing modes (`getSaleData().pricingMode`).** `0 = FIXED`: caps are in quote units and
  `tokens = amount * tokensPerQuoteUnit / quoteDecimalScale`. `1 = ORACLE_USD`: a Chainlink-compatible
  `priceFeed` converts quote→USD at buy time; `tokenPriceUsd` is USD/token (feed decimals); **all caps
  (soft/hard/min/max) are USD**, tracked as `totalRaisedUsd` / `contributedUsd[you]`; quote is still
  held/refunded in its own units (`totalRaised` / `contributed[you]`). Tokens =
  `usd(amount) * 10**saleTokenDecimals / tokenPriceUsd`. See `skills/participate.md` for the exact math.
- **Phases (`getPhases()`).** Empty array = single-phase (use the flat config). Non-empty = multi-phase:
  resolve the **active phase** by `startsAt<=now<=endsAt` (closed intervals; earlier phase wins a shared
  boundary second; a gap → `state == Pending`, no buys) and use THAT phase's `tokensPerQuoteUnit`,
  `phaseCap` (cumulative), `maxBuy` (per-wallet, this phase) and `merkleRoot`. `minBuy` stays global.
  ORACLE_USD is single-phase only, so its `getPhases()` is always empty.
- **State is time- and block-dependent.** Always call `getSaleData()` in the same minute you
  act. The `state` field (uint8) maps to `[Pending, Active, Ended, Finalized, Cancelled]`.
- **Buy only when `state == Active (1)` AND `deposited == true`.** Otherwise `buy` reverts. (In a
  multi-phase gap the state is `Pending`, so this check already blocks buys between rounds.)
- **Native vs ERC20 quote changes the call.** If `quoteToken == 0x0` (native), send
  `buy(amount, proof)` with `msg.value == amount`. If ERC20, `approve` first, then
  `buy(amount, proof)` with `msg.value == 0`.
- **Whitelist:** if the applicable root `!= 0x0` you need a Merkle proof for the buyer address or the
  buy reverts "Not whitelisted". The applicable root is `getSaleData().merkleRoot` for a single-phase
  sale, or the **active phase's** `merkleRoot` for a multi-phase sale (each phase can have a different
  list). You cannot forge it — obtain it from the project's list for that phase.
- **Idempotency:** before re-sending a tx that may have already landed, re-read state
  (`contributed[you]`, `claimed[you]`) to avoid double-spends.
- **Simulate before send.** `eth_call` the exact calldata from the user's address; if it
  reverts, surface the revert reason and stop — do not blindly broadcast.
- **Report provably.** Always return: action, tx hash, block, amounts (human + raw), and the
  resulting on-chain state you re-read after confirmation.
- **HyperEVM big-block lane for heavy txs.** Chain 999 has a ~2M-gas small lane (default) and a
  ~30M-gas big lane. `buy`, `claim`, `claimReferral`, `refund` are tiny — small lane is fine.
  But **launching a token (`createSaleWithNewToken`, ~1.7M) and settling (`createLiquidity` /
  `finalizeAndCreateLiquidity`, ~5–6M) need the BIG lane** or the tx silently won't land. Before
  sending one of those, ensure the sending EOA opted in via the Hyperliquid
  `evmUserModify{usingBigBlocks:true}` L1 action (not an EVM call — use the Hyperliquid SDK). If you
  can't, settle via the split path (`finalize()` then `createLiquidity()`) — but `createLiquidity`
  still needs big blocks. Buyers you act for never need this.

## Files in this skill

- `skills/discover.md` — find & vet sales (read-only)
- `skills/participate.md` — buy into a sale (spends funds)
- `skills/claim-refund.md` — claim vested tokens or refund a failed sale
- `skills/launch.md` — launch a token as a project (spends funds)
- `skills/monitor.md` — watch for state changes and act on triggers
- `reference/launchpad-spec.md` — full data model, ABI, state machine, formulas
- `reference/abi.json` — machine-readable ABIs (factory, sale, erc20, lpFeeVault — the LP
  fee-split vault, not the buyer ClaimVault)
- `reference/addresses.json` — chain + contract addresses (fill per deployment)

## Trust & verification checklist (run before spending)

1. The sale address came from `factory.allSales(i)` or a `SaleCreated` event — not a raw link.
2. `getSaleData().saleToken` decimals/symbol match what the user expects.
3. `softCap`, `hardCap`, `startsAt`, `endsAt`, `tokensPerQuoteUnit`, vesting (`tgeBps`,
   `cliffDuration`, `vestingDuration`) match the user's intent.
4. `lpBps > 0` and an `lpAdapter` is set → liquidity will be seeded & locked (good sign).
5. The amount you are about to spend is `<=` the user's budget AND `<= maxBuy - contributed[you]`
   AND `<= hardCap - totalRaised`.