01The problem

Creator fees are the only durable revenue a pump.fun token has. Every trade in the token pays a fee to the creator wallet, and it keeps paying for as long as anyone trades. It needs no emission schedule, no treasury sale, no counterparty and no promise about the future. It is the one cash flow that exists whether or not the project ships anything else — and by default it accrues to exactly one wallet and stops there.

The obvious use for that revenue is to buy back and distribute the token itself. That is circular, and the circularity is not cosmetic. Paying holders in the asset whose price you are supporting means the reward and the thing being rewarded are the same instrument: every distribution dilutes the recipient's own position the moment they sell it, the "yield" is denominated in a unit whose price is set by the same order book you are buying into, and the number only goes up for as long as the buying continues. It is a mechanism that reads as revenue and behaves as reflexivity.

Paying in a different asset breaks the circle. The reward then carries a price this token's order book has no part in setting, a staker selling their reward does not press on the thing they are staking, and the distribution can be denominated in something with an external mark rather than in units of hope.

That is the whole premise. Everything after this section is what it costs to do it without hurting the people it is meant to pay.

02Why tokenized equities

The reward asset has to satisfy four constraints simultaneously:

1. Externally priced. Its mark is set by a market that has nothing to do with $STOCKPILE.
2. Genuinely transferable. A staker must be able to take custody of it, in their own wallet, and do whatever they like with it afterwards.
3. A claim on something. Backed and redeemable through an issuer, rather than a wrapper around sentiment.
4. Settleable on Solana inside one transaction, cheaply enough that paying hundreds of recipients is not itself the cost centre.

xStocks satisfy all four. They are Token-2022 SPL tokens issued by Backed Finance, 8 decimals, carrying an Xs vanity mint prefix, each tracking one share of a real equity or ETF and redeemable through the issuer. When a staker withdraws, what lands in their wallet is the Token-2022 token itself — not an IOU in this database, not a synthetic balance that only exists on this site.

They also introduce a problem that does not exist for SOL or USDC, and section 03 is entirely about it: the on-chain liquidity of a tokenized equity has no relationship to the size or fame of the underlying company.

03The liquidity gate

Recognisability and on-chain liquidity are uncorrelated. This is the single most important empirical fact in the system, and almost every naive version of this idea gets destroyed by it.

A token appearing in a token list tells you that it exists. It does not tell you that $500 of it can be bought without moving the price by 90%. To find out, you have to quote it. The tables below are measured price impact from live Jupiter ExactIn quotes (SOL → stock), recorded in src/stocks.js on 2026-08-06.

Depth is not impact

Price impact answers "what would this trade cost". It does not answer "how big is the book", and for something that has to keep buying every cycle those are different questions. Pooled liquidity is read separately, live, from Jupiter's market data:

A static list decays

The decisive argument against hardcoding a ticker list is not that a bad list exists — it is that a good list stops being good. GMEx measured 0.302% on one day and 3.961% the next: a 13× move in twenty-four hours, in a name that had already been tiered as comfortably tradeable on the first reading. Worse, the second reading was flat at ~3.95% across 0.05, 0.25 and 1 SOL, which is the signature of a fee-heavy pool rather than a shallow one — so trading smaller does not help.

NFLXx is the same lesson on a longer timescale. It was in the previous generation's rotation. Its pool has since drained to 6.14%, and nothing about the ticker changed to announce it.

Two layers, two different jobs

Depth is a property of the moment, not of the ticker. So the system measures continuously and splits the work in two, with deliberately different tolerances for being wrong:

The gate fails closed, and the failure modes are enumerated rather than collapsed: no route is a refusal; a quote that comes back without a price-impact figure is a refusal, not a zero sorted to the top of the list; an impact above the cap is a refusal with the number attached. The distinction the probe draws between ok === false (measured over the cap) and ok === null (never got a straight answer) matters for the same reason: those are different claims, and only the first removes a name from the rotation. An unanswered stock stays in, because the gate will still stop a bad buy — and being wrong there costs one skipped cycle instead of a delisting.

Layering is what buys that leniency. The probe is allowed to be approximate precisely because nothing it says can move money. And because pickStock() walks the rotation rather than failing on the first refusal, a temporarily thin name costs itself one turn instead of costing the platform a whole cycle.

GMEx is kept in the table on purpose, and it is the honest edge case. At the 1.5% cap the gate skips it on every cycle and the Rotation page says so with the live number next to it. Silently dropping a name people are looking for teaches nobody anything; showing GME sitting at 3.96% and being refused shows the gate working. If that pool tightens, it gets bought automatically, with no code change. That is the entire point of measuring instead of hardcoding.

04Reward accounting

Rewards use accumulated-reward-per-share — the Synthetix/MasterChef pattern — generalised from one reward asset to N, because here every cycle pays a different xStock and a staker accumulates a basket rather than a balance. There is one accumulator per mint.

on distribution:
  acc[mint] += distributed[mint] × 1e18 / totalStaked

pending(user, mint):
  staked × acc[mint] / 1e18  −  debt[user][mint]

The obvious implementation — loop over every staker each cycle and add their slice — is O(stakers) per cycle and rewrites the entire user table every five minutes. The accumulator makes a distribution write exactly one number per mint, so the cost of settling a cycle is O(1) per stock regardless of staker count. A user's unsettled reward is derived on read, touches no other user's row, and is exact.

Dust is carried, never dropped

Both operations are integer division and both floor. What the accumulator can actually pay out is inc × totalStaked / 1e18, which is less than or equal to the amount available; the shortfall is the rounding remainder and it is written into dust[mint] and added to the next distribution of that stock. No base unit is lost and none is silently gifted to whoever happens to sort first. With no stakers at all, the entire amount is carried rather than credited — otherwise the first person to stake afterwards would inherit every cycle that preceded them.

The two cases that make it correct

Both stake and unstake settle before the weight changes, so a change in position size never rewrites what the previous position already earned. Rewards accrue right up to the instant of unstaking, and not one block past it.

05Payout architecture

The naive version of paying stakers is one line: treasury → holder, repeat. It works, and it also draws a picture. Every explorer and bubblemap tool renders "one wallet funded these 400 accounts" as a single bright hub, which is the exact visual signature of a farmed token. The holders are real, the payouts are real, and it still looks fake.

So every payment is routed through a relay: a keypair generated in memory, funded, used and emptied inside one atomic transaction.

1. 1Treasury sends the relay exactly (1 + newAtaCount) × rent lamports.
2. 2The relay opens its own Token-2022 associated token account for the stock, paying its own rent.
3. 3Treasury sends the batch total into the relay's account in a single transferChecked.
4. 4Per recipient: the relay opens their token account (idempotent, relay pays the rent) and transfers their slice.
5. 5The relay closes its now-empty token account; that rent refunds to the relay.
6. 6The relay returns exactly one rent to the treasury, leaving itself at zero.

The consequence is that the on-chain funder recorded against every holder's token account is a wallet which, by the time the transaction confirms, holds 0 lamports and 0 token accounts — and is therefore pruned by the runtime. The link exists for the length of one transaction, and then the account it pointed at no longer exists. A different relay handles every batch and every retry, so there is no second edge to join them back up.

The funding in step 1 has to be exact. A relay that ends with a balance is a relay that survives as a visible account, so the number of accounts it pays for must match the number it was funded for. Where that count cannot be read reliably, the code deliberately over-estimates: under-funding fails the batch outright, while over-funding strands one rent in a dead wallet, which is the cheap direction to be wrong in.

The wire format sets the batch size

A batch is a legacy transaction and it has to fit inside Solana's packet limit. Measured, at seven recipients:

At eight recipients the message is roughly 1270 bytes (25 account keys × 32, two signatures, ~305 bytes of instructions), serialize() throws on every attempt, and the whole run reports everybody unpaid. The batch size is therefore hard-capped at 7 by the wire format rather than by preference, and the compute budget is raised to 400,000 units because the 200k default truncates the tail of a full batch and fails the transaction.

Retries must not double-pay

A transaction the client stopped waiting for can still land inside its blockhash window. Before signing any replacement, every already-submitted signature is re-checked; then the code waits for the previous attempt's blockhash to become permanently unlandable — polling block height against lastValidBlockHeight — while continuing to watch for a late landing. A blockhash stays valid for roughly 60–80 seconds while confirmation gives up at about 50, so without that wait a replacement can be signed while the original is still perfectly landable and both can execute. A duplicate payout is unrecoverable; a slow one is not.

For the same reason, "never left the building" and "on the wire but unconfirmable" are reported as different outcomes. A batch the RPC accepted but nobody could confirm comes back marked unconfirmed, with its signatures, and is explicitly not declared unpaid — a withdrawal refunds a user's balance on a definite failure and must never refund a transfer that lands a minute later.

06Treasury safety

The treasury wallet holds the operator's own SOL and receives creator fees into the same address. The bot must therefore be structurally incapable of spending the former. Its budget is not the wallet balance — it is a decoupled ledger, claimPoolLamports, which only grows by the measured balance delta across a claim, and only shrinks by SOL observed to have left.

Both figures come from on-chain reads taken immediately before and after the action, never from a quoted or requested number. This is not fastidiousness: pump.fun's fee API returns a signature and nothing else — no amount, no receipt, no breakdown — so the only trustworthy answer to "how much did we just earn" is the treasury's own balance. A hopeful parse of a field that stops meaning what it used to would otherwise inflate the pool and authorise spending SOL that never arrived.

Two consequences follow from measuring rather than trusting:

• The delta is net of the fee just paid to claim. That is correct — the spendable pool should only grow by what actually landed.
• A confirmed claim with a zero delta is a success, not a failure: it means there were no fees to collect. Escalating the priority fee and retrying would burn SOL to re-learn the same thing, so only a claim that never confirms is retried.

What the ledger cannot know

A balance delta cannot distinguish fee income from any other SOL that happens to arrive in the same window — a top-up, a sale, a mis-sent transfer would all read identically, and all of them would be spent on stock and become unrecoverable. That ambiguity is handled explicitly rather than hidden: a single-cycle claim above MAX_CLAIM_SOL is quarantined into a held balance, nothing is spent, and a human decides. If it really was fee income, release it; if it was a mistaken transfer, leave it. Fee wallets should only ever receive fees.

The floor

spendable = min(
    pool × (100 − RESERVE_PERCENT) / 100,   // the ledger's permission
    balance − TREASURY_FLOOR_SOL            // the wallet's physical limit
)

The floor is never crossed, so a transaction fee can always be paid even if the accounting drifts. Above that, the rent for opening stakers' stock accounts is subtracted before the swap size is computed, so the buy cannot consume the SOL the payout still needs. A cycle whose spendable pool falls below MIN_CYCLE_SOL is carried over rather than executed thinly.

Signing discipline and custody

• The claim path never blind-signs a transaction handed back by a remote service. It must require exactly one signature and that signer must be this treasury, or it is refused; the blockhash is replaced with a fresh one before signing, since the one baked in was minted before the round-trip.
• The treasury keypair is a private class field, so serialising a claimer into a log line, an API response or an error dump cannot leak it.
• Deposit-wallet private keys are AES-256-GCM encrypted at rest. Relay keypairs are generated at runtime and never stored at all.
• Changing a withdrawal address starts a cooldown before it can be used, so a stolen session cannot instantly redirect funds.
• Solvency is computed publicly: liabilities from the ledger, assets read from the chain. A liability that cannot be priced is counted in full in token units and never netted to zero, and an unreadable chain reports null — an unknown result is never rendered as a pass.
• Boot refuses fatal misconfigurations outright: live mode with demo mode on, live mode without an encryption key or treasury key. Any value still matching a published .env.example placeholder is treated as unset, so an operator who pastes a real treasury key and overlooks the encryption key cannot boot live behind a master key every reader of the repository knows.

07Verification

On 2026-08-06 every one of the 25 xStocks then listed in the universe was bought for real on Solana mainnet, in one run, from one funded wallet.

Three names filled above the 1.5% impact cap: GMEx at 3.956%, UNHx at 1.960% and AVGOx at 1.882%. The routes existed and the swaps landed — that run was a buy-path proof, not a production cycle, and the gate is what a production cycle consults. UNHx and AVGOx were then moved to the rejected set with the numbers that disqualified them, because a name the gate refuses on every cycle is not a candidate, it is noise in the rotation. GMEx was kept, for the reason given in section 03.

Re-running it

None of this asks to be taken on trust. Every claim above is reproducible from the repository against live mainnet, and the read-only checks cost nothing:

npm run probe          # re-measure the whole universe from live Jupiter quotes
npm run verify-chain   # transaction sizing, routing, ATA rent, relay-batch construction
npm run verify-buys    # simulate the real swap for every stock against current chain state

Expect the probe to disagree with the tables in section 03. That is the thesis, not a defect: depth moves, and a paper that reproduced identically a month later would be describing a static list.

08Risks and limitations

This is not investment advice and nothing here is a licensed financial product recommendation. Read this section before staking anything you cannot afford to lose.

• The design is custodial. Staked tokens and unwithdrawn rewards sit in one treasury address. That is a single high-value target, by construction. Encrypted deposit keys, the withdrawal cooldown and published solvency reduce the blast radius; none of them make it non-custodial. Only stake what you accept could be lost to a compromise, a bug or an operator error.
• Rewards are fee-funded and therefore volume-dependent. There is no yield, no APY, no emission and no promise of a return. If trading volume stops, distributions stop. A cycle with nothing to claim distributes nothing and creates no debt owed to anyone.
• $STOCKPILE is a volatile memecoin and can go to zero. Staking it does not protect its price.
• xStocks carry issuer risk. They are third-party tokenized products. Their redeemability, pricing and continued on-chain liquidity are outside this platform's control.
• The gate protects the entry, not the exit. It measures SOL → stock impact at buy time. A staker selling later faces whatever that pool has become — and section 03 is a catalogue of how fast that can change. NFLXx at 6.14% is what it looks like from the wrong side.
• Balance-delta accounting is coarse. It cannot tell fee income from a mis-sent transfer. The claim cap is a backstop, not a classifier.
• Tokenized equities may be restricted where you live and may not be available to US persons. Checking your own jurisdiction is your responsibility, not this site's.
• Infrastructure fails. RPC endpoints, Jupiter routes and the creator-fee API all have bad days. A failed cycle carries over; it does not create a debt.
• There has been no third-party audit, and there is no partnership, endorsement or guarantee of any outcome. Nothing on this page should be read as claiming otherwise. The source is the specification: read it.

09Parameters

Every knob is an environment variable with a default, and the defaults are the safe ones: out of the box the platform boots into a simulation that moves no funds, so the whole system is explorable before a single key exists.