The field manual
Higglespad is a launchpad with one difference: a token does not launch alone. It launches with a population of 1,000, and the population is destroyed by the token's own success.
What Higglespad is
Higglespad is a token launchpad. Anyone can deploy a token through it. What Higglespad adds is a second asset that ships in the same transaction: a collection of exactly 1,000 unique Survivors, permanently bound to that token.
The Survivors are not cosmetic. They hold a claim on a share of the token's trading fees, and their number falls as the token's market cap rises. The two assets are locked in the same loop and neither can be detached from the other.
A launch is finished when one Survivor is left. There is no other ending. A token that never grows keeps all 1,000 alive forever, and the game simply never resolves.
What is live right now
Live on Solana mainnet. Launching a token through Higglespad deploys a real pump.fun coin you sign in your own wallet. Buying and selling here are real mainnet transactions. Market cap is read straight off the pump.fun bonding curve, and the cull ladder is measured against that number — so a population shown on this site is one the chart actually earned.
The registry is the chain. There is no database. A launch registers itself with a memo transaction to 4ioa66…BqX5, and the whole board is rebuilt from that address's signature history on every request. Anyone can reconstruct it without this website.
Culls are recorded on chain. When the market cap crosses a checkpoint, anyone can record it — the execution is not a decision, it is a receipt for something the market already did. Whoever signs it pays the fee, and their signature becomes the permanent proof, linked from the ladder on every launch page.
Not on chain yet. The 1,000 Survivors are derived deterministically from the mint address and rendered here, but they are not yet minted as transferable tokens. The fee routing described under The Survivor Pool is the design, not a shipped contract. Both are marked wherever they appear.
THE ONE RULE
Population moves in one direction. A Survivor that has been burned cannot be restored, re-minted, replaced or bought back, by anyone, including the deployer and the protocol. Market cap falling does not bring anyone back. There is no path in any contract that increases the population above its current value.
Everything else in this manual is a consequence of that rule.
WHY IT IS BUILT THIS WAY
A bonding curve launch gives you one number to watch, and it is the same number on every launch. Higglespad gives you a second one that moves against it. The chart going up is unambiguously good for the token and unambiguously fatal to part of the collection, and every participant sits on both sides of that at once.
That is the entire design. It is not a yield mechanism dressed up as a game. It is a game with a real cost attached to winning.
ONE THOUSAND, GENERATED AT DEPLOY
Every Survivor is a 16×16 pixel character derived deterministically from the launch's collection seed and its own index, 0000 through 0999. Nothing is stored off-chain and nothing is hand-drawn. The same seed and index always produce the same character, so any client can reconstruct the entire collection from two numbers.
Traits are drawn from five slots — headgear, eyes, face, outfit and artifact — on fixed weights. Rarity is the product of a Survivor's trait probabilities, and rank is its position in the collection sorted by that product. Rank does not affect a Survivor's share of the pool, and it does not affect its odds of being selected.
HOW A SURVIVOR IS ACQUIRED
All 1,000 exist from the first block and are held by the launch contract. They are released one at a time, in index order, to each new unique wallet that buys the token, until they run out.
- One Survivor per wallet at release. Buying more does not release more.
- After release they are ordinary transferable tokens and trade freely on any marketplace.
- Survivors still held by the launch contract are not exempt. The ladder does not check ownership before it burns.
This means a launch that reaches its first checkpoint with 300 holders has already put 700 unclaimed Survivors at risk on behalf of nobody.
WHAT A SURVIVOR IS WORTH
A living Survivor holds an equal claim on the Survivor Pool alongside every other living Survivor. That claim is 1 / population, and it re-prices the instant the population changes. A dead Survivor holds nothing and accrues nothing from the block it was burned.
NINETEEN CHECKPOINTS
The ladder is a fixed list of market-cap thresholds and the population that is allowed to exist above each one. It is written at deploy and cannot be edited, paused or reordered afterwards.
| Checkpoint | Market cap | Population after | Burned |
|---|
HOW A CHECKPOINT FIRES
Market cap is read from the pool reserves on every trade. When a trade leaves the market cap at or above a checkpoint that has not yet fired, the selection and the burn execute inside that same transaction, before the trade returns.
- Once only. A checkpoint fires the first time it is touched and is then marked cleared forever.
- Falling back does nothing. A market cap that drops below a cleared checkpoint does not un-fire it and does not restore anyone.
- Skipping is not skipping. A single trade that jumps the market cap across four checkpoints fires all four, in order, in that transaction.
The trade that crosses a checkpoint pays the gas for the burn it caused. Large culls are expensive to trigger, and the protocol does not reimburse the buyer who happens to be standing there.
THE ORDER IS FIXED BEFORE ANYONE BUYS
At deploy, the contract commits to a burn order: a permutation of all 1,000 indices produced by seeding a keyed shuffle with the deploy block hash and the collection seed. The commitment hash is emitted in the deploy event.
When a checkpoint fires, the contract does not roll dice. It walks the committed order from where the last checkpoint stopped and burns forward until the population matches the checkpoint's target. Anyone can replay the shuffle from public inputs and confirm that the correct Survivors were taken.
Every Survivor's position in the burn queue is knowable from block one. The protocol does not hide it and the interface shows it on every Survivor sheet. What is not knowable is how far up the ladder the chart will get.
WHAT THIS RULES OUT
- A deployer cannot spare their own Survivors: the order is fixed before they hold any.
- A holder cannot re-roll: transferring a Survivor moves the asset, not its queue position.
- The protocol cannot intervene: there is no admin function that touches the order or the ladder.
Design, not yet shipped. This chapter describes the intended economics. Fee routing to Survivor holders is not deployed, and no page on this site shows a claimable balance.
WHERE THE MONEY COMES FROM
Every trade on a Higglespad launch pays 1.75%, split three ways and settled in the same transaction.
| Destination | Share of trade | Notes |
|---|---|---|
| Survivor Pool | 1.00% | Split pro rata across living Survivors |
| Deployer | 0.50% | Streams to the deployer until the ladder completes |
| Protocol | 0.25% | Fixed, not adjustable per launch |
HOW IT PAYS OUT
The pool accrues continuously and is claimable at any time. A Survivor's claim is calculated against the population at the moment each fee arrived, not the population today, so a burn does not retroactively hand the dead's unclaimed balance to the living.
What it does do is change every fee from that block onward. A launch that fires THE HALVING doubles the per-Survivor rate on all future fees in a single transaction.
| Population | Claim per Survivor | Multiple vs. genesis | On a $500,000 pool |
|---|
UNCLAIMED BALANCES OF THE DEAD
A Survivor burned with an unclaimed balance keeps it claimable by whoever held it at the moment of the burn. Death ends future accrual. It does not confiscate what was already earned.
ONE REMAINS
The final checkpoint sits at $50,000,000 and takes the population from three to one. The Survivor left standing is the Last.
- It holds 100% of all future Survivor Pool fees, permanently.
- The deployer's 0.50% stream terminates at the final checkpoint and is redirected to the Last.
- The game is marked concluded. No further checkpoints exist and the population can never change again.
A launch that reaches this point has burned 999 characters to produce one. That is the intended outcome and it is stated on the front page of the protocol.
Most launches will never get here. A token that stalls at $80,000 leaves 950 Survivors alive and a pool that grows slowly, forever. That is a legitimate end state and it is the most common one.
WHAT YOU CHOOSE
A deployer picks a name, a ticker, a supply and a ladder preset. Everything else is fixed by the protocol.
- Standard — the 19-checkpoint ladder documented above, ending at $50M.
- Brutal — the same shape compressed into $8M, so the population thins roughly six times faster.
- Long haul — stretched to $250M, for launches that expect to be around for a while.
WHAT YOU CANNOT CHOOSE
- The collection size. It is 1,000 on every launch.
- The fee split. It is 1.00 / 0.50 / 0.25 on every launch.
- The burn order, which is drawn from the deploy block and not from anything you supply.
- Whether the ladder can be edited later. It cannot, by anyone.
NO PRESALE, NO ALLOCATION
There is no reserved Survivor allocation and no team supply. A deployer who wants a Survivor buys the token like everyone else and takes whatever index the contract releases next.
READ THIS PART TWICE
The most likely outcome for any individual Survivor is that it is burned. Nine hundred and ninety-nine out of every thousand are, in a launch that completes.
- The tokens are real and so is the risk. A launch made here is a live pump.fun coin on mainnet. It can go to zero in minutes, and the SOL you spend deploying or buying is gone whether or not anyone else ever shows up.
- Your Survivor is probably going to die. Holding one is a position on where in the burn queue you sit versus where the chart stops. Both are outside your control.
- Growth is the threat. Unlike almost every other asset, good news for the token is the event that destroys part of the collection. Do not buy a Survivor expecting to be protected from the upside.
- Nothing here is reversible. No admin key, no pause, no migration, no snapshot-and-reissue.
- Tokens on this launchpad are tokens. They can go to zero, and a launch at zero simply leaves a large population alive holding a claim on a pool that stopped filling.
- The Survivor collection is not a token yet. Following a Survivor on this site stores a number in your browser. It is not ownership, it is not transferable, and it confers no claim on anything.
- Recording a cull costs you money and buys you nothing. It is a public good: it puts the proof on chain for everyone. Do not do it expecting a reward, because there is none.
EVERY NUMBER IN ONE PLACE
| Survivors per launch | 1,000 |
| Checkpoints (standard ladder) | 19 |
| Major checkpoints | 7 |
| First checkpoint | $25,000 market cap · 1 burned |
| Final checkpoint | $50,000,000 market cap · 2 burned |
| Population floor | 1 |
| Trade fee, total | 1.75% |
| — to Survivor Pool | 1.00% |
| — to deployer | 0.50%, ends at the final checkpoint |
| — to protocol | 0.25% |
| Survivor release | 1 per unique buying wallet, index order |
| Burn destination | 0x0000…0000, non-recoverable |
| Selection source | Keyed shuffle of deploy block hash + collection seed |
| Commitment | Emitted in the deploy event, verifiable off-chain |
| Admin functions | None |
| Ladder mutability | None after deploy |
Ready to see it running? Open a live game or start your own.