How PNFT works
A token's creator fees are routed to a vault that the deployer cannot redirect, and any NFT holder can burn their item for an exact pro-rata share of it. This page covers every mechanic behind that: the fee routing, the vault math, the art pipeline, the full launch → mint → redeem lifecycle, and the parts that are still custodial.
Contents▾
Overview
PNFT is an NFT launchpad built on top of pump.fun. Every token launched through it arrives with a generated NFT collection attached, and the trading fees that token earns become that collection's redeemable floor — a balance of SOL that any holder can withdraw their share of, at any time, by burning their NFT.
Nothing about that sentence is a promise. It is a consequence of where the fees are pointed on-chain, and of arithmetic that a holder can check for themselves. The rest of this page explains both, in order.
Who this is for
- Creators — describe a theme, get a full trait taxonomy and rendered collection, launch a token whose fee stream backs it. See Launch.
- Holders — mint by burning tokens, watch the backed floor rise with volume, redeem whenever the number suits you.
- Traders — every collection publishes a hard backing number beside its market price, so the premium or discount is legible rather than vibes.
The core mechanic
pump.fun accrues creator fees to a program-derived address computed from whoever is set as the coin creatorat creation time. That is the entire hinge of this design. Most launchpads set the creator to the deployer's wallet. PNFT sets it to the collection's vault.
The two highlighted stages are the ones nobody can redirect. Everything left of them is ordinary trading; everything right of them is arithmetic.
Because the creator field is written into the coin at creation and the fee PDA is derived from it, the destination of the fee stream is fixed the moment the token exists. The deployer cannot change it afterwards. Neither can PNFT. The only account that can ever claim from creatorVaultPda(vault) is the vault itself, which is why sweeping is safe to leave open to anybody.
What is trustless today, and what is not
Fee accrual is enforced by the pump.fun program — no part of it depends on PNFT behaving. Fee withdrawal is not yet: in v1 the vault is a server-held keypair and redemption is executed server-side. That gap, and the plan to close it, is spelled out under trust model.
Lifecycle of a collection
Five stages, each of which is covered in detail further down. Status moves generating → ready → live → graduated, with failed as the terminal state if the art pipeline cannot complete.
- 1GenerateA theme prompt becomes a trait taxonomy — a base subject, ordered trait categories, weighted values, and a prompt clause per value. Each item is then rendered as a single image from a single assembled prompt.status: generating → ready
- 2LaunchA pump.fun coin is created with the collection vault as
creator, optionally with a creator buy in the same transaction. The launcher's wallet signs; PNFT never custodies the launcher's keys.status: ready → live - 3TradeEvery buy and sell on the bonding curve accrues creator fees to the vault's fee PDA. This continues after the curve graduates to the AMM.status: live → graduated on curve completion
- 4MintHolders burn a fixed quantity of the token to claim the next unminted NFT. Mint proceeds do not fund the vault — burning is a supply sink, not a sale.
- 5RedeemAny holder burns an NFT and receives
vault ÷ circulatingSOL. The collection can sit at any point of this loop indefinitely; there is no deadline and no expiry.
The vault
Each collection has exactly one vault: a Solana account that is set as the pump.fun coin creator and holds the collection's entire backing. It is the only address that matters for the floor.
Derivation
Vaults are derived, not stored. One master secret backs every collection, and a vault key is sha256(masterSecret ‖ "|vault|" ‖ collectionId). No vault key is ever written to the database, so a database compromise on its own reveals nothing spendable.
Two balances, one number
At any moment a collection's backing lives in two places: SOL already sitting in the vault account, and creator fees that have accrued to the pump fee PDA but have not been swept yet. Both are counted, because unswept fees are already irrevocably owed to the vault — they have simply not been moved.
| Component | Where it lives | Counted in the floor |
|---|---|---|
| Vault balance | the vault account, minus a rent reserve | Yes |
| Unswept fees | creatorVaultPda(vault), net of the platform cut | Yes |
| Rent reserve | 0.0015 SOL held back in the vault | No |
| Mint proceeds | nowhere — minting burns tokens, it does not pay SOL | n/a |
The bootstrap problem
A fresh vault holds zero SOL, because creator fees accrue to the pump PDA rather than to the vault itself. So a vault cannot fund the very transaction that would first fund it. PNFT splits the roles: the vault signs the claim, because only the coin creator may claim its own fees, while the fee payer can be anyone — the wallet pressing the button, or the platform signer when no wallet is present.
Backed floor math
The backed floor is the amount of SOL one NFT is worth if you burn it right now. It is a division, not an estimate.
- vaultLamports
- vault balance minus the 0.0015 SOL rent reserve
- unsweptNet
- fees accrued to the fee PDA, net of the platform cut taken on sweep
- circulating
- NFTs minted and not yet redeemed
Every number in that expression is read live from the chain at request time. The database stores no price and no floor — it stores which items exist and who owns them, and the economics are recomputed on every read. A stale floor is not a failure mode here because there is no stored floor to go stale.
Floor at a glance
For a 24-item collection with every item minted, the relationship is simply linear in the vault balance:
| Vault (SOL) | Circulating | Backed floor (SOL) |
|---|---|---|
| 0.00 | 24 | 0.0000 |
| 1.00 | 24 | 0.0417 |
| 5.00 | 24 | 0.2083 |
| 12.00 | 24 | 0.5000 |
| 24.00 | 24 | 1.0000 |
The redemption invariant
This is the part that makes the number a floor rather than a queue. A redemption removes one NFT and exactly its pro-rata share of the vault — no more, no less. Write V for the vault and c for circulating supply. The floor before redemption is V ÷ c. After:
The floor is unchanged. Whoever redeemed took exactly their share; everyone still holding is exactly as backed as they were a second earlier. There is no first-mover advantage, no bank run, and no last-holder-left-holding-nothing.
What this implies
- Monotonically non-decreasing. Redemptions leave the floor flat; sweeps raise it. Nothing in the protocol lowers it except minting a new item, which requires burning tokens.
- Order does not matter. Whether you redeem first or last, you receive the floor as of the moment you redeem. Waiting is never punished, and rushing is never rewarded.
- It is a closed-end fund's NAV. The backed floor is net asset value per share; the market floor is the share price. The gap between them is a premium or a discount, and the explore table shows both side by side.
- The last NFT is not stranded. At
c = 1the holder redeems the entire remaining vault. The vault does not need other holders to exist for the arithmetic to work.
Fees, in full
There are exactly three places value is taken, and none of them is hidden behind a toggle.
| Fee | Who takes it | When | Effect on the floor |
|---|---|---|---|
| pump.fun trading fee | the pump.fun protocol | every buy and sell | none — never enters the vault |
| Creator fee | the collection vault, via creatorVaultPda | every buy and sell | raises it |
| Platform fee | PNFT — PLATFORM_FEE_BPS, 2000 bps (20%) by default | taken out of each sweep | the remaining 80% raises it |
The creator fee rate itself is set by the pump.fun program's on-chain global fee config, not by PNFT — the protocol reads it rather than choosing it. The platform cut is applied at sweep time, and the floor shown in the UI already has it deducted from the unswept portion, so the published number is what a holder would actually receive rather than a gross figure.
The art pipeline
A collection is generated in two passes: design the taxonomy, then render the items. The split matters — rarity, metadata and de-duplication are all computed exactly from the taxonomy before a single image is requested.
- 1Taxonomy designClaude turns the theme prompt into a base subject, a set of ordered trait layers, weighted values within each layer, and a short prompt clause per value — for example
wearing a backwards red cap. A shared style suffix carries the art direction across every item.model: claude-opus-5 · falls back to a heuristic taxonomy with no key - 2Trait drawTraits are drawn first, weighted per layer. Rarity for an item is the product of its chosen values' probabilities — lower is rarer — and items are ranked from that. Duplicate combinations are rejected at draw time.
- 3RenderEach item is rendered as one image from one prompt assembled out of its trait clauses, eight at a time. Images are written to object storage and the collection cover is composited from the result.fal.ai · Recraft v3 (~$0.04/image) or fast-SDXL (~$0.005) under a $1 per-collection ceiling
Why supply is 12, 24 or 48
Supply is a fixed choice rather than a free field because it is simultaneously an art budget, a floor-dilution parameter and a generation-time parameter. Small supplies keep per-NFT backing meaningful — a collection of 10,000 splits the same fee stream ten thousand ways and the floor rounds to nothing.
Launching a token
The launch is a single transaction that creates the coin and, optionally, executes the creator buy atomically with it. It is built server-side and returned unsigned— the launcher's wallet signs it, so PNFT never holds the keys that pay for it.
- creator
- Set to the collection vault. This is the line that routes the fee stream, and it cannot be changed after creation.
- name / symbol
- Chosen by the creator, never invented by the model.
- uri
- pump-compatible metadata JSON pointing at the generated cover art.
- devBuySol
- Optional creator buy, executed in the same transaction as the create so nobody can front-run the launch between the two.
- mintPriceTokens
- How many tokens a holder must burn to mint one NFT.
Why the transaction needs a lookup table
Create plus ATA setup plus buy references well over thirty accounts. Written out in full the message exceeds Solana's 1232-byte packet limit and the node rejects it before execution — which surfaces in wallets as an unhelpful failed to simulate. pump.fun's own address lookup table replaces those pubkeys with one-byte indices, which is how the whole launch fits in one transaction.
Minting by burning
Minting an NFT does not cost SOL. It costs tokens, and those tokens are burned — permanently removed from supply. This is the sink that ties token demand to NFT demand, and it is deliberately not a sale: no mint proceeds ever enter the vault. The vault is fed by trading fees alone.
- 1PrepareThe next unminted item is reserved and a burn transaction is built against the caller's token account. Balance is checked first, so a holder who cannot afford the burn gets a clear error instead of a transaction that fails in their wallet.
- 2Sign and submitThe wallet signs the burn. Nothing is assigned yet — the burn is the payment, and it must land first.
- 3ConfirmPNFT fetches the transaction, verifies it confirmed without error, and only then assigns the item to the burner. The signature is recorded as the durable proof of the burn.
Tokens are six-decimal against a one-billion total supply, so a mint price expressed in whole tokens is scaled by 10^6 before the burn instruction is built.
Sweeping fees
Sweeping moves accrued creator fees out of the pump fee PDA and into the vault. It is permissionless— anyone may trigger a sweep on any collection, because the money can only ever move to the vault. There is no version of this call that benefits the caller at a holder's expense.
- The vault signs, the caller pays. Only the coin creator may claim its own fees, so the vault must sign; the ~0.000005 SOL network fee is paid by whoever submits.
- The platform cut is taken here. A transfer of
PLATFORM_FEE_BPSof the swept amount is appended to the same transaction, so the split is atomic with the claim. - Sweeping does not change the floor — unswept fees were already counted. It changes where the SOL sits, which is what makes it immediately payable on redemption.
- Graduated collections sweep from two programs. Once a curve completes, fees accrue on the AMM side too and both are queried.
The Claim page surfaces pending fees across every collection a wallet launched and can sweep them in a batch, but a sweep from that page is the same permissionless call anyone else could have made.
Redeeming an NFT
Redemption is the moment the floor stops being a number on a page. The holder gives up the NFT and receives its pro-rata share of the vault in SOL.
- 1Sweep firstAny fees sitting in the pump PDA are pulled in before the payout is computed, so the holder redeems against the true balance rather than a stale one.
- 2Compute the share
floor(backedFloor × 10^9)lamports, read from the vault at that instant. Ownership, mint status and prior redemption are all checked before anything moves. - 3Pay and retire, atomicallyThe item is marked redeemed and the SOL is sent in one server-controlled step. Circulating supply drops by one and the floor for remaining holders is unchanged.
A redemption is recorded as a vault event with the resulting backed floor attached, which is what the floor chart on each collection page is drawn from. The history is the audit trail: every sweep, mint and redemption that ever moved the number.
A worked example
A 24-item collection, fully minted, with 12 SOL of net creator fees accumulated. Follow the floor column down the table.
| Event | Vault (SOL) | Circulating | Backed floor |
|---|---|---|---|
| Launch | 0.00 | 0 | — |
| 24 minted (burns only) | 0.00 | 24 | 0.0000 |
| Fees swept: +12.00 | 12.00 | 24 | 0.5000 |
| Holder redeems | 11.50 | 23 | 0.5000 |
| Fees swept: +2.30 | 13.80 | 23 | 0.6000 |
| Holder redeems | 13.20 | 22 | 0.6000 |
Two things to notice. Minting moved the floor from undefined to 0.0000 without adding a lamport — the burns fed the token, not the vault. And both redemptions left the floor exactly where they found it, at 0.5000 and then at 0.6000. The only rows that moved the number were sweeps.
Architecture
A Next.js App Router application with server-side route handlers for everything that touches a key or the chain. No economics are persisted: the database records what exists and who owns it, and every price, balance and floor is derived at read time.
| Layer | Choice | Notes |
|---|---|---|
| App | Next.js 16 App Router, React 19, TypeScript | Turbopack; economics routes are force-dynamic |
| UI | Tailwind v4, TanStack Table, Recharts, sonner | hairline-dense terminal aesthetic, one accent colour |
| Chain | @pump-fun/pump-sdk, @solana/web3.js, wallet-adapter | Helius RPC, public mainnet as fallback |
| Data | Supabase (Postgres + Storage), Birdeye | in-memory store and local disk when unconfigured |
| Art | Claude for taxonomy, fal.ai for images, sharp to composite | procedural SVG placeholders when unconfigured |
Source layout
- src/lib/pump/
- create+buy transaction building, curve state, fee-vault PDAs, lookup table handling.
- src/lib/vault/
- vault derivation, backed-floor math, sweep construction, redemption payout.
- src/lib/art/
- taxonomy design, per-item render, compositing, storage.
- src/lib/market.ts
- live economics from chain and Birdeye — computed on read, never persisted.
- src/app/api/
- generate · launch · mint · redeem · sweep · portfolio · claim · status.
Graceful degradation
Every integration has a local fallback, so the entire flow runs with zero keys — a heuristic taxonomy, procedural traits, an in-memory store and art on local disk. Adding a key removes a fallback with no code change. The status banner on the explore page reports which integrations are live.
HTTP API
Every route returns JSON. Routes that build a transaction return it base64-encoded and unsigned for the caller's wallet to sign; the paired PATCH confirms the signature landed before any state changes.
Which integrations are configured and live.
All collections with live market and vault economics.
Start the art pipeline for a theme, supply and symbol.
Poll generation progress.
One collection, with derived economics.
Items with attributes, rarity rank and ownership.
Replace the collection cover with a chosen item.
Build the unsigned create(+buy) transaction.
Confirm the launch signature and record the mint.
Reserve the next item and build the token burn.
Verify the burn confirmed, then assign the item.
Sweep accrued creator fees into the vault.
Confirm a wallet-paid sweep.
Burn an NFT and pay out its pro-rata share.
A wallet's items and their redeemable value.
Pending creator fees across a wallet's collections.
Trust model & known gaps
Stated plainly rather than buried, because a floor is only as credible as the honesty of the description around it.
What you do not have to trust
- Fee accrual. Enforced by the pump.fun program. The creator field is fixed at creation and the fee PDA is derived from it, so fees land at the vault whether or not PNFT cooperates.
- Where swept fees can go. Only the vault can claim from its own fee PDA, which is why sweeping is safe to leave open to anyone.
- The launcher's keys.Launch and mint transactions are built unsigned and signed by the user's wallet.
- The published numbers. Vault balance and circulating supply are both checkable independently; the floor is their quotient.
What you do have to trust, today
- Vault custody (v1)
- Vaults are keypairs derived from a server-held master secret, and redemption is executed server-side. Withdrawal authority is therefore custodial even though accrual is not. Replacing the signer with an Anchor program that owns the vault PDA and enforces burn-then-pay atomically is the one remaining step to full trustlessness — and nothing else in the app changes when it lands.
- Off-chain NFT custody
- Minting verifies the on-chain token burn and records ownership against that signature, but the NFT itself is not yet an on-chain asset. Metaplex Core is the intended next step — cheap, native collections, trivial burn.
- No marketplace layer
- Market floor and premium stay null until listings exist. The backed floor is presented on its own rather than padded with an estimate.
- Mainnet-only testing
- pump.fun has no devnet deployment, so launch paths cannot be exercised end to end without spending real SOL.
Glossary
- Backed floor
- Vault balance plus unswept net fees, divided by circulating NFTs. What one NFT redeems for right now.
- Market floor
- The lowest current ask for an NFT in the collection. Null until a marketplace quotes it.
- Premium / discount
- Market floor relative to backed floor, in percent. Negative means the market trades below hard backing.
- Vault
- The per-collection account set as pump.fun coin creator. Holds all backing; the only address that matters for the floor.
- Fee PDA
creatorVaultPda(vault)— where pump.fun accrues creator fees before they are swept.- Sweep
- Moving accrued fees from the fee PDA into the vault. Permissionless; does not change the floor.
- Circulating
- NFTs minted and not yet redeemed. The denominator of the floor.
- Mint price (tokens)
- How many tokens must be burned to mint one NFT. Burned, not paid — the vault receives nothing.
- Graduation
- The bonding curve completing and the token migrating to the AMM. Creator fees continue to accrue afterwards.
- Rarity score
- The product of the probabilities of an item's chosen trait values. Lower is rarer; rank is derived from it.
Frequently asked
Can the deployer take the fees?+
No. The coin creator is set to the collection vault at creation time and cannot be changed afterwards, and the fee PDA is derived from that creator. The deployer has no path to the fee stream — and neither does PNFT beyond the platform cut taken openly at sweep time.
What happens if everyone redeems at once?+
Nothing unusual. Each redemption removes one NFT and exactly its share, so the floor is unchanged for whoever is left. The last holder to redeem receives the remaining vault in full. There is no queue and no advantage to being early.
Does minting more NFTs dilute me?+
Yes, arithmetically — a larger denominator lowers the floor per NFT. That is why minting requires burning tokens rather than paying SOL, and why supplies are capped at 48. Dilution is bounded and known in advance.
Why not put mint proceeds into the vault?+
Because then the floor would partly be holders paying themselves, and the number would stop meaning what it says. Backing comes from trading fees alone, so a rising floor always reflects genuine external volume.
Can the floor go down?+
Only by minting new items, which requires token burns and stops at the fixed supply. Redemptions leave it flat and sweeps raise it. Once every item is minted, the floor is non-decreasing.
Do I have to redeem?+
No. There is no deadline, no expiry and no penalty for holding. If the collection keeps trading, waiting means redeeming against a larger vault later.
Who can trigger a sweep?+
Anyone, on any collection. The vault signs the claim because only the coin creator may claim its own fees, but the caller merely pays the network fee. There is no way to sweep fees anywhere other than the vault.
What if PNFT disappears?+
Fee accrual continues on-chain regardless — the creator field is written into the coin. Sweeping and redemption in v1 depend on the server-held vault signer, which is the specific limitation the Anchor program described in the trust model is designed to remove.