cube³ whitepaper
three burn axes. one solid. supply only shrinks.
00abstract
cube³ is a pump.fun token whose supply only ever decreases. its name is its mechanism — three burn axes acting on a single fixed-supply solid, each grinding tokens against a different friction.
every +5 sol added to the liquidity pool triggers an algorithmic burn (x). every partner token launched through cube³'s launchpad gives 50% of its creator fees back to cube³, which buy back and burn the proceeds every 30 minutes (y). post-pumpswap migration, a transfer hook will route 0.3% of every swap directly to burn (z).
the contract has no operator, no upgrade path, no admin, no team allocation, no presale, no premine. it is a deterministic supply-decay machine. read it on-chain.
01the problem
on pump.fun and most launchpads, a token's supply is fixed at launch and never moves again. value accrual depends entirely on speculative inflow. when attention rotates, the supply stays — a thousand million coins of nothing.
burn-on-launch projects burn a one-time chunk and call it done. holders get a single dilution event, not an ongoing one. once the post lp-burn fanfare ends, the curve is flat for the rest of the token's life.
02thesis
if supply is the only thing a pump.fun token has, then making supply function instead of constant is the only design lever that matters.
three principles fall out of this:
- supply only shrinks. there is no path in the contract that increases supply. no mint, no inflation, no rebase, no team unlock.
- burns are triggered by activity, not time. every burn ties to a real event: lp deposit, partner fee claim, swap. nobody pre-schedules them.
- the rate adapts to price. burn size scales with √(mc/mc₀) — so as the token grows, each burn carves a proportionally larger chunk.
03three axes
x, y, z — three orthogonal pressures on the same finite cube of supply. each axis maps to one pair of faces on the cube. when a burn fires, those two faces flash.
04x · liquidity burn
x watches the cube³ / sol liquidity pool. whenever cumulative net deposits cross a +5 sol threshold, a burn fires.
the size of the burn scales with the current market cap relative to the seed mc:
burn = supply_remaining × p_n
// floor: 500,000 tokens · cap: 5% of remaining supply
this is intentionally sublinear in price. doubling mc only multiplies the burn by √2, not 2 — so a heated market doesn't drain supply too fast, and a cold market still gets a steady minimum cut.
parameters
| param | value | notes |
|---|---|---|
| trigger | +5 sol cumulative lp | resets each fire |
| base rate | 0.05% | at mc = mc₀ |
| scaling | √(mc / mc₀) | sublinear |
| floor | 500,000 | minimum per trigger |
| cap | 5% | of remaining supply |
05y · tribute burn
y is the launchpad axis. when a developer launches their token through the cube³ launchpad, they sign a tribute commitment on-chain: 50% of all creator fees generated by their token, forever, flow to a cube³ buyback wallet.
every 30 minutes, a permissionless keeper calls the claim function. it sweeps creator fees from every active partner pool, swaps the lot to cube³ at market, and burns the result.
partner trade
partners get in return:
- the on-chain cube³ certified badge — a verifiable attestation
- featured slot on cube³.app overview
- promotion post via @cubeburned on x
- priority queue in the cube³ telegram bot
- liquidity bootstrap once mc clears $50k
they keep the other 50% of fees, plus all upside from the token itself.
why partners do this
cube³'s holder base buys partner tokens because every partner buy ultimately routes back to cube³ burns. distribution and price discovery come from a community with structural incentive to participate.
06z · velocity burn
z fires every time a cube³ token moves through a swap. it uses spl-token-2022's transfer hook extension: a small program gets called on every transfer and can re-route a portion to a burn address.
burn_amount = x × 0.3%
net_to_buyer = x − burn_amount
this means liquidity itself shrinks supply: the more cube³ trades, the more it burns. holding-only addresses are untouched (peer-to-peer transfers between regular wallets bypass the hook).
z requires the cube³ pool to migrate to pumpswap first, since pump.fun's bonding-curve amm doesn't support token-2022 hooks. activation is queued behind that migration.
07burn formula · unified
the x and y axes share the same per-event formula. the only difference is the trigger source:
burn = clamp( supply × p_n, floor, supply × cap )
// floor = 500,000 tokens
// cap = 5% of remaining supply
// mc = current usd market cap
// mc₀ = 80,000 (seed mc at launch)
z bypasses this — its burn is a fixed 0.3% of each individual transfer, computed at hook time.
the cumulative effect: supply asymptotes toward zero. it never reaches zero (the floor of 500k tokens means as long as >500k remain, the next burn is exactly 500k — supply could in theory bottom out at a tiny residual), but functionally the chart approaches the x-axis.
08tokenomics
| property | value |
|---|---|
| total supply at launch | 1,000,000,000 |
| decimals | 6 |
| team allocation | 0% |
| presale | 0% |
| premine | 0% |
| liquidity | 100% to lp at launch · burned-key |
| mint authority | revoked |
| freeze authority | revoked |
| upgrade authority | none (immutable) |
every cube³ token in existence came from the public bonding curve at launch. there is no wallet — including the founder's — that received cube³ for free.
09cvs · cube velocity score
cvs is a 0–1 indicator that summarises how aggressively the cube is shrinking right now. it folds three normalised inputs:
- burn rate over the last 24h, divided by the rolling 30d median
- partner-activity index (count of active tribute claims this hour)
- liquidity-deposit acceleration (positive when lp grows)
it is purely informational — the contract makes no decisions based on cvs. it exists so the community has a single legible signal for "how much carving is happening".
10launchpad
the cube³ launchpad is a thin wrapper around pump.fun's launch tx. a developer:
- fills the standard token-info form (name, ticker, image, links)
- signs the tribute pda — a derived account that holds the creator-fee redirect
- broadcasts the combined tx
once confirmed, the token is live on pump.fun with normal creator fees, but the redirect routes 50% to a cube³-owned vault. the keeper bot picks it up on the next 30-minute claim cycle.
certification
the cube³ certified badge is an on-chain attestation issued by the cube³ program. anyone can verify a token is genuinely tributing by reading the partner-registry account directly.
11governance · the absence of it
cube³ has no governance. there is no token-voting, no multisig, no admin key, no off-chain "team decision". the program is deployed with the upgrade authority revoked.
this is deliberate. governance is the most common source of dilution and rug for tokens of this kind, regardless of the founder's intent. removing the option removes the risk.
parameters that could theoretically be changed in a future version:
- base burn rate (currently 0.05%)
- scaling exponent (currently √)
- floor (currently 500k)
- cap (currently 5%)
- tribute % (currently 50% locked at v1)
- velocity hook rate (currently 0.3%)
in v1 none of these are changeable. a v2 would require deploying a new mint and migrating holders — opt-in, on a new contract, never via upgrade.
12on-chain · addresses & programs
verification
every address above is reachable on a public block explorer (solscan, solana fm). source code for the keeper bot and launchpad ix builder is published openly and reproducibly builds to the on-chain bytecode.
13roadmap
- phase 0 mint deployed · 1b supply · lp seeded · keeper bot live complete
- phase 1 x axis (liquidity burn) active · first 5m tokens burned complete
- phase 2 y axis (tribute) live · launchpad open to public devs current
- phase 3 pumpswap migration · z axis (velocity hook) activated q3 2026
- phase 4 partner network reaches 100 live launches · liquidity bootstrap fund q4 2026
- phase 5 cube³ becomes structural backing for pump.fun ecosystem · cvs index public 2027
14risks
this is a memecoin. it can go to zero. specific risks:
- market risk. burns shrink supply but cannot create demand. if nobody wants cube³, the price falls regardless of how aggressive the burn is.
- partner concentration. early on, a few large tributes drive most of the y-axis burn. if those tokens fail, y rate drops.
- keeper failure. the keeper bot is permissionless — anyone can call it — but if no one does, claims stack up until someone profits from running it.
- solana risk. network outages or program-runtime changes affect everything on-chain. cube³ is no exception.
- pumpswap migration risk. z axis depends on a successful migration. if the migration is delayed indefinitely, z stays dormant.
- no operator means no support. there's nobody to roll back a bug. the contract does what its code does. read it.
15footnotes
this whitepaper is intentionally short. cube³ is a small idea executed precisely. the rest is on-chain.
for questions, reach @cubeburned on x or jump into the telegram. there is no investor deck.
this document does not constitute financial advice. cube³ is a fully on-chain experiment with no operator and no guarantees. nothing here promises returns. don't put in more than you can afford to burn.