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 the disclosed 5% fee) — 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 by default — never silently taxed, pooled, or redirected. PYRE takes one disclosed 5% fee, shown in the decoded transaction before you sign.

Why the server can't repoint it. The treasury address and the 5% fee rate 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. So the server cannot quietly repoint your rent to another address or inflate the fee — a change to either would be a code change that has to go through review, not a runtime config flip. 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 and the 5% fee lines exactly as they appear in the decoded transaction.

The fee is disclosedand shown pre-sign — the cleanup is not “free,” and no return or gain is implied.

Spawn launch economics — where your Essence goes

The 5% cleanup fee is the only deduction on your cleanup transactions. It 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. 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 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.

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.

Full transparency on where your Essence goes: consumed into the Spawn at launch and claimed pro-rata on graduation; returned if a round fails to launch. No return or gain is implied.

Cleanups between rounds — your fee SOL is refundable, not token-bearing

Almost always there is an open round to feed. But if you clean up in a brief window between rounds — when no round is open — your disclosed 5% cleanup fee still 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 fee 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 the fee paid 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), a gap fee 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 between-rounds cleanup fee is returned to you in SOL by the operator. It carries no token allocation and no permissionless on-chain refund. No return or gain is implied.

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 the 5% cleanup fee.
• It is the operator's revenue, and it offsets a real cost. Launching costs the operator SOL up front (pump.fun mint and bonding-curve rent, most of it unrecoverable, plus any dev-buy it subsidizes beyond the round's Essence). 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 silently. Recovered rent returns to you by default; the only deduction is the disclosed 5% fee, shown pre-sign.
• 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.