Provable, not promised

You hold your keys

PYRE never holds your private keys. Every transaction is built unsigned, decoded, and shown to you — you sign it in your own wallet. There is no custodial signing, by design. There is no private-key environment variable anywhere in PYRE, and there never will be.

1. Build (unsigned). When you choose accounts to close or tokens to burn, PYRE assembles an unsigned transaction. Nothing can move yet — no signature exists.
2. Decode. The raw transaction is decoded instruction-by- instruction: which accounts close, which tokens burn, the rent amount, the rent destination (your wallet), and the disclosed fee.
3. Match. The decoded contents are matched against the preview you see. The fee leg is independently re-verified against a build-time trust anchor (see rent). A mismatch is a literal refusal to sign — not a warning you can click past.
4. You sign. Only then does your wallet ask for a signature. The key never leaves your wallet. PYRE cannot sign for you.

Proof: the FAQ answer(“Do you ever sign for me?”) and the non-negotiable trust rules in the public repo's CLAUDE.md.

This is a mechanicalfact — you are in control of signing. It is not a promise that any token is “safe.”

Secured by a 2-of-4 multisig

The on-chain program's upgrade authority and the fee treasury are the same Squads v4 2-of-4 multisig vault. Changing the program or moving treasury funds needs 2 of 4 independent signers. No single developer key can do it alone.

What “2-of-4” means: four independent signers hold keys to the vault; any action — upgrading the program, moving funds — requires at least two of them to approve and sign. One compromised or rogue key cannot act. This is the difference between a project with a single dev who could rug at any moment and one where control is split and checkable on-chain.

Proof: the vault on Solscan ↗ (also the destination of contributions to the PYRE) — controlled by a 2-of-4 Squads v4 multisig. On Solscan it appears as the program-owned vault account; its 2-of-4 threshold and signer set are enforced on-chain by the Squads program. Full addresses are in on-chain addresses below.

This states the mechanism(2-of-4) — it does not claim the project is therefore “safe.”

Independently reviewed

The on-chain program has been reviewed in depth. Findings were fixed and the program was redeployed. The deployed build is byte-identical to the reviewed binary (sha256 d5e95d03…), verified on-chain after the multisig redeploy.

What this review is — plainly. This is our own in-depth review process, not a paid third-party firm audit, and we do not claim otherwise: an internal multi-agent code review of the on-chain program, a standing security review maintained alongside the code, and the byte-identical-build verification that proves the deployed program matches the reviewed source on-chain. It is a real, ongoing security practice — not a certificate from an outside auditor.

• Internal multi-agent code review. An in-depth review of the Anchor pyre-core program; the findings it raised were fixed and the corrected build was redeployed.
• Trust-path review.An end-to-end review of the decode-match → sign path that gates every signature; it found the funds-carrying path airtight after the fixes landed.
• Full protocol review. A broad review across the codebase; the findings it surfaced were addressed and verified.
• Standing security review. An ongoing security review of the on-chain program is maintained alongside the code.

Byte-identical build. The program now running on Solana mainnet was built from the reviewed source and is byte-for-byte identical to the reviewed binary (sha256 d5e95d03…). Because the program's bytes are on-chain, anyone can verify the deployed program matches the reviewed build — you do not have to take our word for it.

Proof: the on-chain program on Solscan ↗. Full program id is in on-chain addresses below.

A review reduces risk; it does not eliminate it. Always do your own review. A review reduces risk by finding and fixing issues — it does not prove the absence of bugs, and it is not a guarantee.

Your rent comes back to you

Recovered account rent returns to your wallet in full — never taxed, pooled, or redirected. PYRE takes no fee on your rent. The only amount a cleanup can route to PYRE is a contribution you opt into yourself, shown in the decoded transaction before you sign.

Why the server can't repoint it. The treasury address and the maximum any fee leg may reach are baked into the app as build-time constants, and an independent client-side check re-verifies the fee leg against those constants right before your wallet is ever asked to sign. Reclaimed rent is not a fee base at all: a rate can only bite on lamports the code explicitly declares feeable, and a cleanup declares none — so the skim cannot be switched back on by configuration, only by a code change that goes through review. This client-side anchor is a published part of the trust path (trust-anchors.ts, checkFeeAnchor).

Proof: the honest economics and the example receipt on /about show the rent → you line exactly as it appears in the decoded transaction.

Network and priority fees are paid to Solana, not to PYRE, and are shown pre-sign. No return or gain is implied.

Spawn launch economics — where your Essence goes

Nothing is withheld from your rent inside your cleanup transaction. If you choose to feed the PYRE, that contribution becomes your Essence — an on-chain contribution to the current round, recorded as your pro-rata (in-proportion) share. Launching a Spawn is a separate operation, and that operation has its own cost: a 0.06 SOL launch flooris reserved out of the round's pooled Essence at ignition, half of it retained by PYRE — see the launch floor below. Here is exactly what happens to that Essence, honestly.

The live model — on-chain and trustless

PYRE's Spawn distribution runs on the trustless on-chain program (pyre-core, program id 4SaAiTS2…), deployed to Solana mainnet under the 2-of-4 Squads multisig upgrade authority. Your contribution is not held on an operator's word — it lives in a program-owned vault, and the flow is enforced by the contract:

• Essence locked in a program-owned PDA vault.Your contributed SOL is held in a smart-contract vault — a program-derived account (PDA) owned by the program's own code. No operator key, and no single signer, can move it.
• Consumed into the Spawn at launch.When a round fills and its Spawn launches (Ignition), the round's Essence — after the 0.06 SOL launch floor is reserved out of it — is consumed into that Spawn and locked. From that point it is not individually refundable — it has become the Spawn the ritual produced.
• Pro-rata claim on graduation. When the Spawn graduates — its pump.fun bonding curve completes and it moves to open trading — the vault opens and each contributor pull-claims their pro-rata Spawn-token share, the same terms for everyone, with no operator cut of the supply. The protocol may also auto-distribute on graduation; the pull-claim at /claim is always available as the trustless floor.
• Fails to launch → returned, permissionlessly. A round that does not launch returns your exact contribution via a permissionless refund — no operator action required. A permissionless force_fail_roundbackstop, callable by anyone once the round's grace window elapses, ensures funds can never be trapped.
• Launched but never graduates → pinned recovery, not a personal refund. If a Spawn launches but its curve never completes, the round's vaulted position is recovered along a path whose destination is pinned on-chain by the program — recovered value can only go to that pinned destination, never an operator wallet. It is a recovery of the position, not an individual SOL refund of your contribution.

What “consumed” means in plain terms: feeding a round is not a deposit you can withdraw at will. Before a round launches, your contribution is refundable if the round fails. Once it launches, your Essence has become the Spawn — you then hold a pro-rata claim on the Spawn, not a claim to get your SOL back. We disclose this plainly so there is no surprise.

The launch floor — 0.06 SOL reserved at ignition, half of it retained

A round cannot launch until it has accrued at least 0.06 SOL of Essence. That floor is not seed money for the Spawn — it is reserved out of the round's pooled Essence at ignition, before anything reaches the bonding curve, and it splits in two. We state both halves, including the half PYRE keeps.

• 0.03 SOL — the launch cost, spent on-chain. This pays for the launch transaction itself: the pump.fun create, the token accounts it needs, priority and network fees, and the tip. It is spent, not retained — it leaves for the chain.
• 0.03 SOL — operational margin, retained by PYRE. This half is simply not spent: it stays in the treasury and covers ongoing operating overhead (servers, RPC providers, maintenance). Because the operator keeps it, it is a real deduction from the round's pooled Essence — this 0.03 SOL does not become Spawn tokens for anyone, contributors or operator. It is disclosed, not hidden, and it is not taken from your reclaimed rent.
• Everything above the floor seeds the Spawn.The round's accrued Essence minus the 0.06 SOL floor is the dev-buy — it buys the Spawn on its own bonding curve, and that position is what contributors claim pro-rata. The further a round grows past the floor, the smaller a slice of it the floor is.

It is charged once per launch, not once per contributor.The 0.06 SOL comes off the round as a whole — not 0.06 SOL from each person. Because the remainder is split pro-rata, the floor reduces every contributor's claim by the same proportion; no one absorbs more of it than their share. Once the floor is first met the round waits 12 hours before auto-firing, so more Essence can accrue in the meantime.

Why it is spelled out here. /aboutalready discloses the same 0.06 SOL floor and the same 0.03 / 0.03 split. It belongs on this page too, in full, so that reading the proof page leaves you no less informed than reading the explainer: your contribution is not the only place value comes off on the way to a Spawn.

Earlier Spawns. Before on-chain rounds, some early Spawns were launched operator-run and operator-refunded on failure. Those are historical; the live model is the on-chain vault described above.

Proof: the vault, claim, refund, and force-fail mechanics are enforced by the open-source pyre-core on-chain program (program id 4SaAiTS2…) deployed under a 2-of-4 Squads multisig upgrade authority. No single key — including the operator key — can unilaterally move contributor funds. The program source is in programs/pyre-core/ in the public repo. The launch-floor numbers above are the constants the launcher actually runs on — LAUNCH_COST_SOL, LAUNCH_MARGIN_SOL, LAUNCH_FLOOR_SOL and the 12-hour LAUNCH_TIMER_MS in packages/core/src/launch-policy.ts, also in the public repo.

Full transparency on where your Essence goes: the 0.06 SOL launch floor is reserved first (0.03 spent on the launch transaction, 0.03 retained by PYRE as operational margin), the remainder is consumed into the Spawn at launch and claimed pro-rata on graduation; your whole contribution is returned if the round fails to launch. No return or gain is implied.

Cleanups between rounds — contributions made in the gap

A cleanup between rounds deducts nothing from your rent, because no cleanup does. If you choose to feed the PYRE while no round is open, that contribution goes to the treasury wallet as a plain SOL transfer. We call that a gap burn, and we disclose exactly how it is handled so there is no ambiguity.

• Gap SOL is refundable. A gap burn is recorded against the round it is carried into, and the operator returns the exact SOL to your wallet via a treasury-signed refund. You are made whole for what you fed during the gap.
• It is not Spawn-token-bearing. A gap burn does not earn a Spawn-token allocation. Spawn tokens are claimed from an on-chain receipt, and a gap burn — a plain SOL transfer to the treasury — has no on-chain receipt to claim against. So a gap burn is refunded in SOL, never converted into a token share.
• There is no permissionless on-chain refund for it. Unlike an on-chain round contribution (which you can self-refund on-chain via the program if a round fails), gap SOL went to the treasury wallet, not a program-owned escrow. Its refund depends on the operator running the refund — it is an operator commitment, recorded and auditable, not a smart-contract-enforced refund.

Disclosed plainly: a contribution made between rounds is returned to you in SOL by the operator. It carries no token allocation and no permissionless on-chain refund. Historically, when cleanups still carried an automatic rent fee, gap fees were refunded on the same terms. No return or gain is implied.

Transmute — selling a scrap token to SOL

Some junk tokens are still worth a little. A transmute is a Jupiter swap that sells one of them for SOL. PYRE builds that swap unsigned, your browser decodes it and runs a fail-closed safety scan against it, and you sign it in your own wallet — the same build → decode → you-sign shape as a cleanup. The SOL lands in your wallet. PYRE never takes custody of it.

Where the proceeds go — to you

The swap's output is wrapped SOL, unwrapped straight into your own wallet. There is no PYRE-held intermediate account and no operator step between the sale and you. Before the transaction is ever shown to you, the server simulates it and requires that yourwallet's lamport balance goes up by at least the slippage floor — a simulation that does not clear that floor is refused, not displayed. The built transaction must require exactly one signature, and it must be yours: a transaction that asks for a second signer, sets a fee payer who is not you, hands token authority to anyone but you, or closes an account to any destination but your wallet is refused before it reaches your screen.

An honest asymmetry, stated rather than glossed.A Jupiter swap is a third-party, multi-instruction, lookup-table-loaded transaction with an opaque route, so it cannot be pinned instruction-by-instruction the way PYRE's own close/burn transaction is. The browser check on the swap is a fail-closed safety scan, not the burn path's full byte-match — if any referenced lookup table cannot be resolved, the scan refuses rather than assuming the hidden instructions are benign. It is a real check and it fails closed, and it is not as airtight as the burn match. We would rather say so than imply otherwise.

The protocol fee — the mechanism, and where the rate comes from

When PYRE charges a fee on a transmute, it uses Jupiter's native platform fee: the rate is set on the quote and Jupiter deducts it from the swap's output inside the same transaction, crediting a treasury-controlled wSOL fee account whose address is disclosed to you in the pre-sign preview. Because the fee is part of the swap itself, it can never show up as a separate transfer you were told nothing about, and it can never take more than the swap actually produced.

The rate itself is server configuration, and this page deliberately does not print it. It lives in PYRE_SWAP_FEE_BPS (packages/config/src/index.ts), an operator can change it without shipping any code, and it may be set to zero. This page is statically rendered, so a figure written into it would be a build-time copy of a runtime value — a number we could not promise to keep. The figure in the pre-sign preview is the authoritative one— the fee shown there, both as a SOL amount and as a rate, is what the transaction you are about to sign will take, whatever it says. When the configured rate takes nothing, the preview omits the fee row entirely and simply shows the net you receive. PYRE's own fee arithmetic is cross-checked against Jupiter's quoted platform fee before the transaction is built: a divergence of more than one lamport (integer rounding) refuses the build rather than showing you a number you would not actually be charged. And a quote that comes back carrying no platform-fee block at all is refused too — PYRE will not build a swap whose fee it cannot account for, in either direction.

Whatever that rate is, the market charges you separately.A transmute executes against live liquidity, so the price you actually get carries the pool's own spread and price impact. That cost is real at any protocol-fee rate, including none at all, and it is not PYRE's to waive: PYRE refuses the swap outright when price impact exceeds the configured ceiling, but it will never tell you a sale costs you nothing.

Selling contributes nothing — Essence is a separate, explicit act

Swapping a scrap token to SOL does not feed the PYRE. Nothing is contributed by signing the swap. If you want to commit part of what you realized, that is a second transaction — you choose the rate, you see the amount, and you sign it separately.

• Computed from the confirmed swap, not the quote.Slippage means the SOL you actually realize differs from the estimate, so the committed amount is derived by the server from the landed transaction's own on-chain record after it confirms. You see the real number before signing.
• Capped at half the proceeds. A commitment can never exceed 50% of what the swap realized (MAX_TRANSMUTE_COMMIT_BPS = 5000 in packages/core/src/swap.ts). That is a hard domain ceiling: operator configuration can only narrow it, never widen it. The default offered rate is 0 — a plain sell.
• The commitment leg is byte-matched. Unlike the swap, this second transaction is PYRE-built and single-instruction, so it ismatched against its preview at the burn path's strength. The leg that actually moves SOL to PYRE is the one you can verify completely.
• The platform fee is not your Essence.Any fee taken on the swap is PYRE's cut, disclosed pre-sign — it is never recorded as a contribution on your behalf. A skim is not a commitment.

What is refused, rather than best-effort swapped

Swapping is held to a stricter standard than burning: a burn destroys a token, while a swap transfers it through third-party routing where an unusual token can behave in ways PYRE cannot reason about. Anything in the list below is refused outright — you are told it was skipped, and nothing is attempted.

• Token-2022 with a blocking extension. A transfer hook (arbitrary code runs on the transfer), a permanent delegate(an authority can move or burn holders' funds), confidential transfer (unsupported), a transfer fee (it skims the proceeds, so what you receive would not match the preview), or a pausable configuration (transfers can be frozen mid-flow).
• Token-2022 whose extensions could not be verified on-chain. Unknown means skip: if PYRE could not read the mint's extensions, it cannot rule out one of the above, so it refuses.
• Anything the classifier does not mark transmutable. Tokens marked PROTECTED or UNSUPPORTED — and anything else outside the transmutable class — are never swapped. An unknown token program is refused for the same reason.
• Hard risk signals from Jupiter Shield. Honeypot, non-transferable, and frozen-authority flags refuse the swap outright rather than merely warning you.
• No usable route, or too much price impact. A missing quote, a missing price-impact figure, or price impact above the configured ceiling all refuse. A route existing is never on its own enough — every gate must pass.

As everywhere else on PYRE, a token clearing these checks appears eligiblebased on current checks. It is never a claim that the token is “safe.”

Your rent stays yours, and stays separate

When a transmute closes the emptied token account, the reclaimed account rent is yours — exactly as in a cleanup (see your rent comes back to you). It is reported alongside the transmute figures and never folded into them: rent is not proceeds, not a fee base, and can never become Essence. It is also only counted when the transaction bytes actually show that account being closed — if the built swap does not close it, the rent figure is reported as zero rather than assumed.

Proof: the refusal gate and the commitment ceiling are evaluateSwapEligibility, SWAP_BLOCKING_EXTENSIONS and MAX_TRANSMUTE_COMMIT_BPS in packages/core/src/swap.ts; the platform-fee enforcement, the one-signer scan and the simulate-and-assert step are buildSwapTx in packages/solana/src/tx-swap.ts; the browser-side fail-closed scan and the burn-strength match on the commitment transaction are decodeSwapSafety and matchTransmuteCommit in apps/web/src/components/swap-decode.ts. All of it is in the public repo.

Disclosed plainly: a transmute sells a scrap token for SOL that lands in your wallet; PYRE takes no custody of it; PYRE's cut is a protocol fee taken out of that swap's own output at a server-configured rate that may be set to zero, and the pre-sign preview is always the authoritative figure; the market's own spread and price impact apply either way; committing any of the proceeds as Essence is a separate transaction you choose and sign, capped at half the proceeds. A review reduces risk; it does not eliminate it. Always do your own review.

How PYRE earns — pump.fun creator fees (disclosed)

PYRE has a revenue source, and we disclose it plainly: when PYRE launches a Spawn, PYRE's launcher is the on-chain creator of that token, so it earns the pump.fun creator fee— a share of the Spawn's trading volume paid out by the pump.fun protocol to the token's creator.

• It is paid by the market, not by you.The creator fee comes from pump.fun, funded by the Spawn's trading activity. It is never taken from your Essence, your reclaimed rent, or your contribution.
• It is the operator's revenue, and it offsets a real cost. Launching costs SOL up front (pump.fun mint and bonding-curve rent, most of it unrecoverable, plus any dev-buy the operator subsidizes beyond the round's Essence). To be precise about who pays: the first 0.03 SOL of that on-chain launch cost is covered by the round's own Essence via the launch floor, not out of the operator's pocket; anything beyond it falls on the operator. Creator fees accrue to a pump.fun creator-vault controlled by the operator and are how that cost is offset over time.
• It does not change your allocation. Contributors still receive their full pro-rata Spawn share — the creator fee is a separate pump.fun stream and does not reduce what you claim.

Disclosed, not hidden: PYRE earns from Spawn creator fees, paid by the market — never from your cleanup or your contribution.

On-chain addresses

Every address below is copyable and linked to Solscan. Verify them yourself.

What PYRE will never do

• Never hold your keys. There is no private-key environment variable, by design — signing is always client-side in your wallet.
• Never auto-sign. No transaction is ever executed without you signing it yourself, after the decode-match preview.
• Never tax your rent.Recovered rent returns to you in full; the only amount a cleanup can route to PYRE is a contribution you opt into, shown pre-sign. Separately — and also disclosed — a 0.06 SOL launch flooris reserved from a round's pooled Essence when its Spawn launches.
• Never call a token “safe.” The classifier only says a token appears eligiblebased on current checks — anything it can't safely reason about is skipped, untouched.
• Never promise a return. No yield, no profit promise, no guaranteed gains. Any Spawn share is pro-rata and the same for everyone.

A review reduces risk; it does not eliminate it. Always do your own review.