The mechanic in full.

A bundle is a large block of a new token's supply, bought cheap at the mint, before anyone else can bid. From outside, nothing tells you it exists, how big it is, or how fast it can be sold. A Sheaf bundle is one as well. The difference is that the block is declared when it is created, and the same program bounds how fast it can leave.

That bound is one number in one account, written once, and no instruction rewrites it. The program is specified to deploy with no upgrade authority, so the number cannot be raised afterward. Every bundle runs sell-only mode: the trading rule sells above a reference price and never buys. The reference ratchets up on sustained strength and has no path back down. The program contains a buy branch, refuses to create a bundle in any other mode, and records the mode in one byte anyone can read, so that branch never runs. What that gives a reader is a narrow claim: the selling rule is a published function, not a promise. This is not a commitment to hold, and no part of the design makes anyone better off for holding. It is a published rate, and the rate is not generous: at most a quarter of the declared block in any one window, a fixed span of at least one hour counted from launch, and at least four windows from launch to nothing. On every bundle, that is at least four hours.

Of about 2,300 lines, the trading engine is the highest-risk part: every swap, every price read, every oracle path and every signed call into a third-party program lives inside it. Three bounds used to make shipping it without a review survivable, and two of them are now gone. Every bundle that enables the engine runs it sell-only, so the provable no-trade property no longer exists, and the program is now open to every creator, so the one-bundle ceiling is gone too. The one that holds is that the exit path imports neither the engine, the oracle, nor the venue, which a test enforces rather than a paragraph. That trade was made deliberately and the reason is in § 02.

Seven instructions in order. Six of the seven can be called by anyone, which is the point: no account in this design holds a privilege, and there is no operator to compromise or to subpoena.

/01The funding window

initialize_bundle creates the bundle account and writes every immutable parameter in one transaction, taking the creator's first deposit through the same code path every later deposit uses. Fourteen ordered checks run and the handler fails on the first one that does not pass. A zero disposal cap is refused outright, because a zero outflow cap would trap the token leg forever.

deposit transfers quote in and mints exactly one share base unit per quote base unit. Never scaled. The cap is checked against a counter in the bundle account rather than against the vault's balance, because anyone can inflate a token account with a bare transfer, and a griefer who could close a raise with a one-unit donation would be a real defect rather than a theoretical one.

For every bundle the funding window is a formality: the program refuses to create a bundle unless its first deposit equals the cap, so initialize_bundle fills it with the creator's own capital in the same transaction that creates it. No later deposit can succeed, from anyone, because the cap is already full.

A bundle is full or it does not exist, and that is a required property rather than a preference. The reason is arithmetic: the three allocations are declared at creation and sum to the cap exactly, and a partial fill would leave a declared amount the vault does not hold. The program refuses a cap above 150 SOL and a tier-clearing allowance above 5 SOL. The worked example sits at both ceilings: 86.50 SOL of launch, up to 5 SOL of tier clearing and 58.50 SOL held as quote, 150 SOL in all; a creator's launch costs about 92 to 150 SOL, depending on the reserve they declare. Graduation itself measured 86.07 SOL, so the launch cap carries about 0.43 SOL of margin against a change in the curve fee, and because the launch buy is exact-out, the unused part stays in the vault. A proportionally allocated partial fill is a V2 problem and is not bolted onto this.

/02The launch

execute_launch creates the token on the pump.fun curve and buys it in one transaction, then measures what actually arrived and writes that measured amount as cap_basis_base, the fixed basis every later cap is computed against. It revokes the share mint authority in the same handler, so the share supply is fixed before anything trades. Every failure path leaves the bundle in its funding state, so the instruction is retryable and a creator's deposit is never stranded.

Atomicity here is composition rather than a special instruction: there is no combined create-and-buy on the venue, and Solana already treats one transaction as all or nothing. The measured cost of doing both in one transaction is in §07, and the one part of this that is still open is in §08.

/03Clearing the fee boundary

clear_tier exists because of one sharp number in §03: the coin-creator fee steps at 420 SOL of notional market cap, and a token that has just graduated sits about 2.2 percent below it. The instruction makes a single capped purchase targeting 430 SOL, and it fails closed in every direction. The program refuses, on every bundle, a tier-clearing cap above 5 SOL or a target above 450 SOL of market cap, so no creator can size it into a large buy. If the required spend exceeds its cap, or the buy would land short of the target, the whole transaction reverts and the vault spends nothing. A failed attempt costs the caller a transaction fee and the vault nothing at all.

It cannot live inside execute_launch, because the curve caps at completion and migration is not atomic with it, so the pool it needs to trade does not exist in that transaction. It is the only instruction whose success is asserted against an outcome rather than an action, which is why tier_cleared reading true is evidence the threshold was crossed rather than a record that something ran.

/04The rule the crank runs

crank is the trading step, and on every bundle that enables the engine it is live and sell-only. It sells when live spot is above the reference by more than the band and does nothing otherwise, which is most of the time. The buy branch is compiled into the same instruction, because the mode is one value of one immutable field rather than a separate code path, and the program accepts only 1, sell-only, in that field. So every buy evaluation on every bundle stops at gate 7 with BuyDisabled, error 6062. A creator who asks for 2, two-sided, is refused at creation. The crank never succeeds as a no-op, so a caller always learns which gate stopped it.

Two properties make the rule checkable rather than merely stated. The reference only ratchets up. It advances on sustained strength, after a set number of confirming observations and a minimum interval, and there is no path in the program that lowers it. So the level the vault sells above never falls, and no sequence of trades can lower it. And every parameter is written at creation and never again, the step is a pure function of on-chain state plus a price anyone can post, and the caller is anyone. At any price, from state at a given slot, a third party can compute whether the vault will sell and how much. Nobody decides it at the time, which is the difference between a published function and a promise.

harvest_fees sweeps the fee inbox into the vault, less the protocol fee. 10 percent of the creator fees other traders paid goes to the wSOL account of Sheaf's fee wallet, 636QyjGvmpZF7EdByzXdrLqzN4XKNKoeT3HPNTSYniv2, and the fees the vault's own trades paid come back whole. The rate and the wallet are compiled into the program, so no creator chooses them, and once the upgrade authority is revoked no one can change them. The venue's own fee collection requires no signature from anyone, which means a third party can trigger it directly. Pointing the venue's destination at a dedicated inbox account, rather than at a vault leg, is what makes harvest_fees the only path out of that inbox, and it is the reason the fee accounting is exact rather than approximate.

/05The exit

redeem burns shares and transfers a pro-rata slice of two balances. It is 92 lines of arithmetic with no external dependency: two multiplications, two divisions, two transfers and a burn. §06 is why it pays in kind rather than in cash, which is the single most consequential design decision in the document.

Both figures published in public circulation for the pump.fun creator fee were wrong, and the schedule turned out to matter more to this design than anything in it. It was read directly off the account.

Three readings fall out of it. The liquidity leg and pump.fun's own leg are constant above the bottom tier, at 20 and 5 basis points, so the coin-creator leg is the entire variable and the total runs from 120 basis points down to 30. The widely cited 0.30 percent is the bottom of the schedule, not the rate. And the bottom tier is not on that curve at all: below 420 SOL the split is 2, 93 and 30, which is a penalty band on small pools, and it is exactly where every freshly graduated token starts.

/06How the ambiguity was settled

The account carries two 25-tier tables, one for ordinary pools and one for stable pools, and which one applies changes the creator leg by more than 3x in the window this design lives in. It was settled against live pools rather than by reading documentation, because there is none. Eight pools were sampled across four orders of magnitude of market cap, computed from their own pre-swap reserves, and six of the eight land on the predicted tier exactly.

One pool settles it alone. At 10,373 SOL of market cap and 453 SOL of liquidity it pays a 70 basis point creator leg. The ordinary table on a market-cap basis predicts exactly 70. The stable table predicts 30 on a market-cap basis and 90 on a liquidity basis. Neither is close, and both readings of the stable table are separately falsified by two other pools in the sample.

The schedule was then reconciled at the lamport level against one live sell. Two mechanical facts came out of it that appear in no documentation and that any adapter has to get right: the liquidity leg never leaves the pool, so it is invisible in the transfer list, and pump.fun's own leg arrives as two transfers rather than one. Code that counts fee transfers, or assumes a single protocol recipient, misparses every swap.

/07Before graduation the fee is flat

The bonding curve has its own fee account, and it carries no tiering at all: a flat 125 basis points, 95 to pump.fun and 30 to the creator. The 25-tier table applies only after graduation, on the pool. This also explains the bottom tier, which totals the same 125 basis points, so the fee does not jump at migration. It has one hard consequence for the build: the slippage floor on the launch buy is computed against the flat curve rate, not against the tiered table, and getting that wrong in either direction either fails every launch or accepts an unbounded one.

/08What the trading costs, and what is not known about whether it pays

Because the liquidity and protocol legs are constant, a trade the vault makes into its own pool pays 25 basis points that come back to nobody. That leak is exactly 25 basis points and it is invariant across all 25 tiers, before priority fees, before tips and before any sandwich. Fee income, meanwhile, accrues from third-party volume whether or not the vault trades. Income depends only on other people's turnover and cost depends only on the vault's, with no term coupling them, so on fee arithmetic alone the optimal amount of vault trading is none.

The two-sided design this replaced paid that cost on purpose, for positioning rather than fee economics, and whether it served a funder reduced to one number: how often a token that has fallen below the reference comes back above it, given that the reference only ratchets up. A round trip that completes captures the band. One that does not leaves the vault holding a falling asset. That number was then measured, and it set the mode.

Eight accounts, seven for a bundle with no strategy, and 0.02079 SOL of rent for the set. There is no global state account of any kind, and no field anywhere that names an account with a privilege.

/09What is deliberately absent

There is no refund, no transfer_position, no claim_fees, no close, no pause, no set_ anything, no instruction that lets anyone but a bundle's creator fund it, no vote, no stake, and no global state account. There is no buy in the trading rule on any bundle: the engine's buy branch is compiled in, and every bundle's mode, written at creation, is sell-only, so it never selects it. There are no position accounts, because the share is a plain fungible mint and the token program already tracks who holds it.

The refund path is the redeem path. A failed raise, or a funding deadline that passes, leaves the token leg nonexistent, so the pro-rata arithmetic pays quote back one for one through the same handler. One code path, one test set, and one fewer instruction to review.

The strongest sentence the design supports, and it is deliberately narrow: on every bundle, once the tier clears, nothing moves the vault's quote anywhere except to a redeeming holder, pro rata. The one other branch that spends quote is the engine's buy branch, and the field that would select it is immutable and set to sell-only. The protocol fee does not touch the vault's quote: it is split off in the fee inbox before the rest reaches the vault. That is checkable by inspecting a seven-instruction program with no upgrade authority and reading one byte of one account, which is the only reason it is worth writing down.

The error enum is complete at 71 codes, numbered from 6000, and the ordinals appear in client code and in explorer output, so they are not reordered.

Enforcement is the whole subject. A cap that a privileged account can raise is a promise, and a promise is what this design is trying not to make. Every bound below is a compiled constant, an arithmetic check that cannot overflow, an absent instruction, or a test that fails the build.

// state.rs, compiled into the artifact. A creator may configure under these
// and nobody can configure over them, because there is no instruction that writes them.

MAX_FLOW_CAP_BPS         = 2_500        // 25% of the basis, per window, ceiling
MAX_TRADE_CAP_BPS        = 100          // 1% per trade and per window, ceiling on all four rate caps
TIER_CLEAR_SPEND_CEILING = 5_000_000_000   // 5 SOL, the most any bundle's tier purchase can spend
TIER_CLEAR_MCAP_CEILING  = 450_000_000_000 // 450 SOL of market cap, the highest tier target
PROTOCOL_FEE_BPS         = 1_000        // 10% of organic creator fees, no other value accepted
PROTOCOL_FEE_OWNER       = 636Qyj...niv2  // full key in § 02 /04
HARD_TVL_CEILING         = 150_000_000_000 // 150 SOL per bundle
MIN_INITIAL_DEPOSIT      = 5_000_000_000   // 5 SOL, the smallest cap a bundle
                                           // can declare, since it must equal the cap
MAX_VENUE_FEE_BPS        = 200          // above this the engine halts, it does not drain
MIN_WINDOW_LEN_SECS      = 3_600        // one hour, both windows
MAX_WINDOW_LEN_SECS      = 86_400
BPS_DEN                  = 10_000

// initialize_bundle also refuses every mode but 1, sell-only (check_strategy).

/10The disposal rate, and the honest version of it

The cap is flow_cap_bps, a per-window allowance in basis points of cap_basis_base, at most 2,500, the compiled ceiling, against a window of at least 3,600 seconds and at most 86,400. Both are written at creation, and the worked example uses the fastest pair the program accepts, 2,500 over 3,600. It bounds all token outflow by any path: a sell the engine makes and a holder redeeming draw on the same allowance. On a bundle that enables the engine both paths are live, because the engine runs sell-only, and they draw on the same allowance. The engine's own selling is held separately, to at most 1 percent of the basis per trade and per window on every bundle, a twenty-fifth of this ceiling. The gate fails closed with no partial fill, so a request over the line does not receive part of what it asked for.

Three details in the gate are load-bearing, and each one exists because the naive version is wrong. The clock is clamped forward, because a clock that regresses would otherwise reopen a spent window. The allowance is computed through a 128-bit intermediate, and this is mandatory rather than stylistic: a token with a billion units of supply at six decimals is 1e15 base units, and the basis multiplied by anything above roughly 18 basis points overflows 64 bits for a realistic token. And the window carries part of the previous window forward on a sliding term, because a pure fixed window admits two full allowances in two seconds: spend the cap at 59:59, spend it again at 60:01. The sliding term refuses that second spend. It does not make the cap hold over any 60 minutes. It counts the previous window's outflow as if it had been spread evenly across that window, so a burst at the end of one window is under-weighted in the next. Measured in a VM test harness against the real program, with every over-ask refused, a sequence timed across a boundary moved 1.9994 allowances inside an interval just under one hour.

/11The basis, and why it is fixed

cap_basis_base is set to the measured amount the launch actually received, amended exactly once by clear_tier, and frozen the moment tier_cleared is true. A test enforces both halves of that: textually, that the field is assigned in exactly two files, and behaviorally, that a sell and a redemption after the tier clears leave it unchanged.

The rejected alternative is the one most designs pick, which is to compute the allowance against the current balance. That reintroduces geometric decay: the allowance shrinks as the balance does, the vault can always keep selling, and the published unwind time becomes infinite. A fixed basis makes the drain linear and the unwind finite, and it is the only version of the cap that can be published as a number.

/12The size caps

The per-bundle ceiling is 150 SOL, compiled in, with the per-bundle field checked against it at creation. At runtime deposits are bounded by a counter in the bundle account rather than by the vault's balance, for the griefing reason in §02. 150 SOL is not a round number chosen for comfort: 25 SOL cannot buy graduation at any plausible threshold, 100 SOL works only at the low end and leaves almost no reserve, and 150 SOL buys graduation across the range. In the worked example it leaves 58.50 SOL declared as quote, which nothing spends except a redemption, since every bundle is sell-only.

Each bundle belongs, by its address, to the creator who signs for it. The bundle account is derived from the seeds ["bundle", creator, slot], and the creator signs initialize_bundle, so each creator has up to 256 slots and no one can open a bundle at another creator's address. The program then refuses the bundle unless the creator's first deposit equals the cap, so no one else can ever deposit into it. Both rules are arithmetic in the handler rather than a flag, so there is nothing to flip. A boolean flag would be a privileged operator and a claim a reader has to trust. Arithmetic in an immutable program is a claim a reader can check.

/13What fails closed, and by what mechanism

• Compiled constants. Everything in the block above. There is no instruction that writes any of them.
• Checked arithmetic. Every add, subtract and multiply on a balance is checked, with 128-bit intermediates where a 64-bit product can overflow. Overflow checks are on in the release profile, and a test denies bare arithmetic outside the math module.
• Assertions that revert. The window gate, the launch slippage floor, the tier spend ceiling, the tier outcome check, and the venue fee ceiling, which halts the engine rather than letting it drain.
• Absent instructions. No setter, no pause, no close, and no upgrade authority. A deposit from anyone but the creator is refused by arithmetic, because the cap is full at creation.
• One immutable field. The buy branch is compiled in, every bundle runs sell-only mode, and every buy evaluation fails at gate 7 with BuyDisabled.
• Ten tests that fail the build, not style checks: the exit path's import boundary, release builds excluding the mock venue, no floating point anywhere, no unchecked arithmetic, account sizes matching the byte map, the published offsets holding still, the compiled protocol fee and its wallet, a verifiable build, the basis being written by exactly two instructions, and the tier flag implying the threshold was crossed.

A holder redeems for a fraction of two balances. No price is consulted, no oracle is read, and no net asset value is computed anywhere in the program. That is a deliberate refusal, and this section is the arithmetic that forces it.

// ix/redeem.rs, 92 lines. Eight accounts: no venue, no oracle, no strategy, no pool.
// That account list is the specification. If it grows, something has gone wrong.

supply     = share_mint.supply                          // read live
quote_out  = floor( vault_quote × shares / supply )
base_out   = floor( vault_base  × shares / supply )
require( quote_out > 0 or base_out > 0 )                  // else DustRedemption
if launched and base_out > 0: gate_admit_flow( base_out )   // flow_cap_bps only
burn( shares ); transfer( quote_out ); transfer( base_out )

Both legs floor, always against the redeemer, and the remainders accrete to whoever has not redeemed. The final redeemer holds the whole supply, so both expressions reduce to the full balance and the vault empties exactly. The token leg is gated by the disposal cap and nothing else. The engine's reserve floor binds the engine only and never a redemption, because a floor that can stop a holder reaching their own pro-rata assets has stopped being a constraint on the vault and become a constraint on the holder.

/14The wedge that makes cash redemption a run

Selling tokens into a constant-product pool pays at most the pool's quote reserve scaled by the fraction of the combined token balance being sold. Written out, selling N tokens into a pool holding M tokens and R quote pays R × N / (N + M), so the share of the marked value that a sale realizes is M / (N + M), and it falls as the position grows relative to the pool. Splitting the order does not help, because price impact is path-independent in a static constant-product pool.

Applied to the worked example's day-zero position, with 150 SOL deposited, that produces two numbers for the same holding. Both are published, at the same size, and that is a rule rather than a courtesy: a marked figure never appears on any surface without the realizable one beside it.

A redemption that paid out at the marked figure would let the first redeemer take 3.1x their fair share and leave the last one holding a tail nobody will buy. That is a run, by construction, on day one. Paying at a liquidation mark fails differently: redemption pressure becomes sell pressure, and the caps that exist to bound the vault's selling would then block redemptions instead.

In-kind payment is the only version in which the program never states a value it has to honor. It transfers a fraction of two balances. There is no mark to overstate, no oracle to consult, no sequencing advantage and no run. What a holder does with the tokens afterward is their decision and their price, and the program has no opinion about either.

/15The exit is isolated from everything that could break

One rule overrides local convenience anywhere in the codebase: the redeem handler must not import the venue, the oracle, or the strategy. Two tests enforce it. One parses the file and asserts none of those names appear. The other builds and submits a redemption in which the venue program, the price account and the strategy account are all absent from the transaction, and asserts that it succeeds. The behavioral test is the real one; the textual test catches the intent earlier.

What that buys is a single column in the design's own failure table. Pool drained, venue frozen, venue bricked, price feed stale, price feed offline, token worthless, nobody running the crank: the exit path is unaffected in every row, because it does not call any of them.

/16Shares, and the absence of a payout

Shares are a plain fungible mint with no freeze authority, minted only inside a closed funding window at one share unit per quote unit, and never again. The mint authority is revoked during the launch, so the supply is fixed before anything trades, before any fee accrues and before there is a price. Share inflation is structurally impossible rather than merely prohibited, and there are regression tests for it anyway.

Harvested fees land in the quote vault, and every share's claim is its fraction of that balance. Supply is frozen, so every harvest raises every holder's claim pro rata, instantly, with no bookkeeping, no distribution instruction, no schedule, and nothing sent to anyone except the protocol fee, which is split off in the fee inbox before the rest reaches the vault. That costs nothing to build and it removes a privileged action, since posting a distribution root is a privilege and this design has none. It also has a cost worth stating plainly: a holder cannot take income without reducing their position.

Four calls settle every claim in this document that is about Sheaf. The offsets are published so the check works with curl and xxd rather than with our client, because a verification that requires running our software is not a verification.

// 1. the program
getAccountInfo( [program id] )
  executable                            → true
  its ProgramData upgrade authority     → None        // stop here if it is not

// 2. the bundle
derive PDA ["bundle", creator, 0] under the program id
getAccountInfo( that PDA )
  length                                → 480 bytes
  owner                                 → the program id
  u8   at offset 10  strategy_enabled  → 1            // the engine is live; step 3 reads its mode
  u8   at offset 11  slot_index        → 0
  u8   at offset 12  tier_cleared      → informational
  u32  at offset 16  window_len_secs   → 3600 to 86400  // never under an hour
  u16  at offset 20  flow_cap_bps      → 1 to 2500 (little endian)
  u16  at offset 22  protocol_fee_bps  → 1000
  u64  at offset 392 cap_basis_base    → the other half of the unwind figure

// 3. the strategy account, and the one byte that fixes the mode
derive PDA ["strategy", bundle] under the program id
getAccountInfo( that PDA )
  length                                → 576 bytes
  u8   at offset 9   mode              → 1            // sell-only, the only value accepted
  // no instruction writes it, so every buy evaluation stops at gate 7, BuyDisabled

// 4. nobody but the creator funded it, same bundle account
  32 bytes at offset 24  creator       → the key in the PDA seeds
  u64  at offset 312 tvl_cap_quote     → the cap
  u64  at offset 376 escrowed_quote    → equal to the cap
  // initialize_bundle refuses a first deposit below the cap, so every later deposit fails

A one at offset 10 means the engine is live, and the strategy account at the derived address holds every parameter it runs on, each written at creation and never again. A one at offset 9 of that account means the engine sells and never buys, for the life of the bundle. A nonzero value at offset 20 means the position is redeemable, because a zero outflow cap would trap the token leg. Equal values at offsets 312 and 376 mean the creator filled the cap at creation and nobody else could deposit. Dividing the vault's token balance by the basis multiplied by the rate, over a 10,000 bps denominator, gives the live unwind figure in windows, which is the number to read rather than any constant printed in a document.

/17Separating the vault's trades from everyone else's

This is the part with no equivalent elsewhere, and it is what makes the determinism argument true rather than decorative. A deterministic rule whose trades cannot be told apart from organic flow produces the same misleading tape as a discretionary bot, with a stronger claim attached to it. So every vault trade is attributable by anyone, from the program id and the bundle's address.

// Every vault swap ever, chronologically: one call, keeping the ones that succeeded and whose instruction
// is this program's crank or clear_tier. Anyone can list the marker in an unrelated transaction, so the
// second filter is required, not optional. No interface definition needed and no
// cooperation from us. The marker is derived per bundle.
getSignaturesForAddress( findProgramAddress( [b"vault_trade", bundle], PROGRAM_ID ) )

// Attribute an individual swap: the swap's own user token account is one of ours.
swap.user_base_account  == findProgramAddress( [b"sh_base",  bundle], PROGRAM_ID )
swap.user_quote_account == findProgramAddress( [b"sh_quote", bundle], PROGRAM_ID )

// The figure this makes computable, and the only honest way to show volume:
organic = pool_quote_volume − sum( VaultTrade.quote_amount )
//   published as "24h volume X, of which Y was the vault's own"

The marker is an address and nothing else. It holds no data, needs no rent, and is never read or written; it is simply present in the trading instruction and in nothing else the program does, which is what makes filtering on it exact. A structured event carries the side, the measured amounts, the reference the trade fired against and the venue fee, and its discriminator is derivable without our interface definition. Gross pool volume is never published without the vault's share broken out, because a number that mixes the two is the one thing this design cannot afford to show.

/18The deploy sequence, and the step that gates the rest

The mainnet artifact is built verifiably and its hash is recorded per commit. The step straight after the deploy is the one everything else depends on: the deploy script revokes the program's upgrade authority before any bundle exists, reads the ProgramData account back and asserts it is None. Nothing else proceeds until that assertion passes. After the revoke, any creator can still open a bundle, and nobody, the builder included, can change the program that governs it. Nothing else in this design survives an upgrade authority existing.

Before a launch, the launch script re-reads pump.fun's own constants account and confirms the graduation figures have not moved, recomputing and rebuilding the parameter set if they have. After it, the verification script runs against the new bundle and publishes its output, with the live unwind figure rather than a constant.

/19What can be measured about the venue, and how

• A program-derived address can hold the coin-creator role, and claim the fee. Settled four independent ways: a live curve mint whose creator field is a program address; 701,113 such addresses system-wide, so it is the ordinary case rather than an edge; two live pools with off-curve creator values carrying real accruing balances of 0.068931873 and 0.673158261 SOL at slot 451,504,240; and decisively, the venue's fee-collection instruction has zero signer accounts in its own interface definition, so the claim path needs no signature from anyone.
• Off-curve is the test. A program-derived address is by definition off the ed25519 curve and a wallet is always on it. Sampling 25 live pools, 12 have an off-curve creator. The test was validated offline first: 40 of 40 genuine public keys read on-curve, and random byte strings read on-curve about 46.5 percent of the time, as expected.
• The pool layout was anchored before it was read. The creator field sits at offset 211 of the pool account, and the layout was confirmed by reading the quote mint at offset 75 on five live pools and getting wrapped SOL on all five.
• Creating a token and buying it in one transaction costs 174,308 compute units, measured on a live mainnet transaction carrying a real 4.94 SOL buy, which is 12.5 percent of the per-transaction ceiling and leaves roughly 1,200,000 units for the launch handler's own bookkeeping. Treat it as a measured floor rather than a fixed cost, and read §08 for the part of this that is still open.

The design's own attack table runs to nineteen rows. These are the ones a reader outside the build should weigh, in the order they would cost the most, with the figure that sizes each one.

1. /20
   Nobody outside the build has read the code, and the highest-risk third of it is the part that touches other people's programs.

   An audit at the scope this deserves costs many times what the whole project has, and the decision was to keep the trading engine and accept no audit rather than cut it to fit a review. The two-sided decision then added roughly 400 lines back and turned the engine on. The sell-only decision that followed set the mode without removing any of that code, so the buy branch is still compiled and still unreviewed, and the sell leg is live on every bundle that enables the engine. Five defects were found by two teams reading the same specification; at that rate the remaining count is not small. A test matrix is the only defect control the program gets, and whatever it does not exercise ships unexercised.
   2,327 nSLOCthe engine included, reviewed by nobody
2. /21
   Once deployed, there is no upgrade authority, which also means a bug cannot be patched.

   This is the cost of the property that makes everything else on this page checkable. The same field that stops anyone replacing the program also stops anyone fixing it. There is no pause instruction and no privileged account to call one.
   Noneupgrade authority, revoked right after deploy, before any bundle exists
3. /22
   The fee income depends entirely on a parameter a third party can change in one transaction.

   The venue's fee account carries a mutable admin, and pump.fun can set every creator tier to zero. There is no hedge and no contractual recourse. Watching the account and publishing the last-read rate is the whole mitigation, and it is stated as a first-class term rather than a footnote.
   Byte 9the mutable admin of an account this design does not own
4. /23
   The program signs into a third-party venue program, and that signature propagates.

   This is the highest-severity row in the design's own table. A signature passed into a venue travels down that venue's own call chain, and a malicious or upgraded venue could use it to move the vault's whole token balance. The bounds are a pinned venue program, a dedicated shuttle account that limits what the signature can reach, and disclosure. The venue programs are upgradeable: the curve, PumpSwap and pump fees programs share one upgrade authority, read from mainnet on 2026-10-01. That makes this row live, not hypothetical.
   Criticalrated total loss in the design's own attack table
5. /24
   A program can create a token and buy it in one call sequence. That is proven on a mainnet fork, not yet on a live cluster.

   The mechanical case is sound: the venue's create instruction requires signatures only from the fresh mint and the buyer, the buy instruction requires only the buyer, the creator signs neither, and neither instruction guards against being called by a program. The 174,308 unit measurement in §07 comes from a live transaction with both instructions at top level from a wallet. The open question was whether a wrapping program could do the same by internal call. The release build did, against the real pump.fun program on a mainnet fork: create and buy in one launch transaction, the curve complete in that transaction. No live cluster has run it yet.
   Forkproven against the real venue, not on a live cluster
6. /25
   The vault sells the token it launched, and that conduct is disclosed here rather than argued away.

   A vault trading both sides of its own token would sit close to the fact pattern prosecutors have charged, and the two-sided design fit it more closely than a one-directional seller. Every bundle is sell-only: the program refuses two-sided at creation, and the mode byte shows it. Even sell-only, it is still a risk. The vault sells a token it created into a pool where outside holders trade, and a reader should weigh that. The structural answer is unchanged: the rule and every parameter are published before any trade, no person chooses to place one, and the caller is anyone, so the vault cannot pick its own timing. That answer depends on the attribution in § 07 working, which is why it is built rather than promised. It is an argument written by engineers, not a legal opinion. Counsel review is no longer a launch gate, and it has not happened.
   Discloseda one-directional seller of its own token, not reviewed by counsel
7. /26
   The position is marked at several times what it can realize, and an interface that showed only the mark would be misleading.

   The wedge is 3.1x on total value and closer to 5x on the token leg alone at day zero. The arithmetic is in §06 and it is not a modeling choice. The residual risk sits entirely in the interface and the disclosure, which is why the rule about never showing one number without the other is written down.
   3.1xmarked over realizable, on the day the bundle launches
8. /27
   The modeled median outcome for a funder is a loss.

   The funder is the creator, the only depositor. It was modeled before the 10 percent protocol fee, which can only lower it. The median ticket is down roughly a fifth, and the mean only clears break-even because of a single row in 336. The distribution is a right-skewed lottery, and the median is the number to read. §09 has the rest.
   0.82x to 0.9xmodeled median, against a mean carried by one row in 336
9. /28
   Anyone can extend the unwind by sending tokens the program cannot refuse.

   A bare transfer into the vault adds tokens that sit outside the cap basis, so they lengthen the real unwind beyond the published figure. This cannot be fixed by tracking, because no program can decline an incoming transfer. It is why the unwind is published live rather than as a constant.
   Unboundedby design, and stated rather than hedged
10. /29
    Hostile mints are refused rather than handled, extension by extension.

    pump.fun creates every mint under Token-2022, so the program requires that standard and refuses, at launch, any mint carrying an extension that would let a third party move, block or tax the vault's tokens: a permanent delegate, a transfer hook, a transfer fee, a default frozen state, non-transferability, a pause authority, confidential transfers or a close authority. It also requires the mint to have no freeze authority and no mint authority. A transfer fee would break the delta measurement the cap basis depends on, and a permanent delegate could take the vault's tokens outright. Refusing these is a real limitation and it is the correct one here.
    Refused8 extensions, plus any freeze or mint authority
11. /30
    The securities analysis is flagged and not resolved, and the design does not improve it.

    A token sold to fund a named team to build a product is a well-known fact pattern and this one is not a close call. Nothing in the program's design reaches an investment-company exemption, because a freely transferable fungible share on a permissionless chain cannot count or qualify its holders. Rate-gated rather than on-demand redemption, and in-kind rather than cash payment, are partial mitigants at most. This is flagged for counsel and is not a matter the code settles.
    Unresolvedflagged, not mitigated, not advice
12. /31
    SHEAF, the project's own token, has no role in the protocol.

    SHEAF is a plain pump.fun token, created on pump.fun's own site, and not a Sheaf bundle: it has no vault, no speed limit and no graduation at launch. It carries no claim on the protocol fee or on anything else, and no bundle is quoted in it. The builder receives its pump.fun creator fees, which is a second conflict of interest beside the protocol fee. Any purchase the builder makes at its creation is published with its address.
    Discloseda plain pump.fun token, with no claim on anything

Two rules govern this section. The unfavorable number is never the smaller one on the page. And figures that are reconstructions rather than measurements are either labeled as such or left out, which is why some of the internal model's more interesting numbers are not here.

/32Where a launch lands, and what the pool keeps

A pump.fun token graduates at about 85.0 SOL of buying, which is about 410.9 SOL of notional market cap, read from the venue's own constants account. On a fixed supply of a billion, that buying takes about 793.1M tokens off the curve and leaves about 206.9M as the migration reserve that seeds the pool.

Two consequences follow immediately and neither is a forecast. 420 SOL is the first fee tier, so a token that has just graduated is one tier below it and about 2.2 percent of price away, which is the sharpest parameter in the whole design and the reason clear_tier exists. And selling the entire position straight back into the pool it just seeded pays about 67.41 SOL against about 86.08 SOL spent, a 0.78x round trip that is fixed the moment the pool exists and is independent of everything that happens afterward. That 18.67 SOL is not a fee, a spread, or bad execution. It is the pool keeping the tokens it was seeded with.

/33The funder distribution

In a measured cohort of 336 graduates, 22 reached a 500,000 dollar market cap within four hours and one reached it later, so 313 never did. The median current market cap of those 22 is now under 4,000 dollars. The base rate for graduation itself, measured over 118,229 launches on a comparable venue, is 1.70 percent, rising to 4.45 percent for launches carrying a real site and a real description. Every Sheaf bundle graduates inside its own launch transaction, so that rate describes the tokens around it, not these.

Against those base rates the modeled median funder outcome, before the protocol fee, is a loss of roughly a fifth, and the mean clears break-even only because of one row in 336. The favorable branches of the internal model are reconstructions built on tier boundaries that were never decoded and on a path assumption nothing measures, so no favorable multiple is published here. The direction that survives the reconstruction is enough on its own: operating income is not monotonic in success, because the creator leg steps down as the pool grows, so a larger token pays less per unit of volume. The exact turning point is a reconstruction output and is not published.

/34What the builder risks and earns, and what a creator risks

The builder plans to fund one bundle, the first, scheduled for Thursday, October 15, with his own SOL. It runs under the same program and floors as any creator's and has no power theirs lack, and his exposure on it is a creator's, below. Beyond it, what the builder puts at risk is the deploy, about 4.5 SOL of program rent. What the builder earns is the protocol fee: 10 percent of the creator fees other traders pay, on every bundle, his own included, sent to one wallet compiled into the program. That is a conflict worth naming. The fee pays on volume whether or not a bundle's creator comes out ahead.

A creator's exposure is the launch itself. The launch buy measured 86.07 SOL, capped at 86.50, and selling the whole position straight back into the pool it seeded returns about 0.78x, as /32 shows. The floor is a plausible outcome, not a tail: 313 of the 336 measured graduates never reached a 500,000 dollar market cap. Each bundle is one party's own capital, which is the posture the program was built on; pooling strangers' money into an unaudited vault was considered and rejected.

Every figure on both pages traces to a row here. Where two internal documents disagree, the disagreement is printed rather than reconciled quietly.

/35Open, and material

• Whether create and buy in one call sequence works on a live cluster. Proven on a mainnet fork against the real pump.fun program; no live cluster has run it.
• What the venue's upgrade authority does next. The venue programs are upgradeable under one authority, read from mainnet on 2026-10-01. That keeps the signature-propagation risk in §08 live for the life of the vault.
• The graduation constants. Read once from the venue's constants account and not independently re-derived. They are re-verified immediately before deploy rather than before the parameters are written, because a launch sized against stale constants fails.
• Tiers 7 to 22 of the fee schedule. Not decoded. 25 tiers spanning 95 to 5 basis points implies some steps smaller than 5, so the real curve is probably smoother than any reconstruction of it. Nothing on either page draws that span, and every internal figure keyed to a reconstructed boundary is withheld.
• The decode slot for the fee account. Three different slots appear across the internal documents for the same read: 451,494,845, 451,497,521 and 451,497,970. The decoded contents agree, and the live-swap reconciliation at slot 451,499,060 is the unambiguous one. The discrepancy is a bookkeeping defect in the internal record and is printed rather than picked over.
• The engine's reserve floor. Three internal documents disagree about whether it exists in V1 and on which account it lives. What holds on every bundle regardless is structural: once the tier clears, nothing spends the vault's quote except a redemption, because the only branch that would is the buy branch and the mode never selects it. The protocol fee does not change this, because it is split off in the fee inbox.
• The launchpad build. Creator-keyed bundles, the self-funded rule, the per-bundle marker and the protocol fee are being built now. The fork run and the measured figures on this page come from the build before them.
• Cited case law and regulatory releases. Referred to internally from secondary reading rather than from the originals, so none of it is cited on these pages and none of it should be treated as settled here.