What the program can do, and what it cannot.

Perpetua is non-custodial. When you add an asset, your wallet approves the Perpetua program, through a program-derived address unique to your switch, as delegate on that token account for the amount you choose. The tokens stay in your account. Your wallet still shows them and you can still use them.

SOL works the same way. The amount you set aside is wrapped into a reserve account that you own, at an address derived from your switch so trading apps never touch or close it. That reserve is delegated to the switch. Removing SOL or cancelling unwraps it back into your wallet in the same transaction.

The delegation can only be used by the program, and the program only uses it after your interval and the 7-day grace period have passed without a check-in. At that moment the assets move into an escrow account owned by your switch and are delivered to your heirs.

Program address (mainnet, deploying soon)

PerpX2pWbVffrbJfb4zbDtGkJeWGyucH2HVPkvdpDit

Upgrade authority

Published at deployment

Verified build

The mainnet binary is built reproducibly with solana-verify from the public source at github.com/1Caine/perpetua-program, and its hash is checked against the deployed program. Solscan shows the verified badge once the verification job has run against the deployed program.

security.txt

Embedded in the program binary, and published at /.well-known/security.txt.

On mainnet the upgrade authority is a Squads multisig, so no single key can change the program. Fees and limits are constants in the program code: changing them requires an upgrade signed by that multisig, which is public onchain.

Perpetua has not had a third-party audit yet. We say so plainly because inheritance is a long-term commitment and you should weigh it.

What has been done:

• A program test suite covering every instruction, every failure path, early-execution attempts at the exact second, wrong signers, substituted accounts, changed delegations, partial balances, closed and frozen accounts, and heir account creation.
• A stateful fuzzer that runs thousands of random sequences of owner actions, wallet activity, time jumps and permissionless execution, checking value conservation, exact shares and timing after every step, plus thousands of hostile account substitutions.
• A mainnet-fork rehearsal against the real mainnet Token, Token-2022 and Associated Token programs, with real USDC, wrapped SOL and a live pump.fun Token-2022 coin.
• End-to-end runs on a live validator: create, check in, timer expiry, execution, letter decryption, buyback and burn.

A letter is encrypted in your browser with a random 256-bit key (AES-256-GCM). The key never leaves your browser whole. It is split into two shares, and the letter key is the two shares combined.

1. Share A is sealed to your heir's letter key. The heir creates that key once by signing a fixed message with their wallet. Wallet signatures are deterministic, so the same wallet always recreates the same key, and the key never leaves the heir's device.
2. Share B is sealed to the Perpetua release key. The release service hands share B to the heir only when the heir proves control of the named wallet with a fresh signature, the switch account (read at finalized commitment) shows that execution has started, and the letter's hash matches the one you wrote onchain for that heir.

Before execution, the heir holds only share A and the service refuses share B. Perpetua can open share B but never share A, so Perpetua can never read a letter. The sealed envelope (ciphertext only) is stored permanently on Arweave, and its SHA-256 hash is recorded onchain in your switch, so anyone can confirm it was not altered.

If an heir has not created a letter key yet, you can still seal a letter to the release key alone. The app labels this clearly: in that mode the release service could technically read the letter, so we recommend asking your heir to create their key first.

Why not Lit Protocol: Lit retired its access-control network in 2026 and moved to a single hosted environment. A letter may need to open decades from now, so we chose a design whose rules are enforced by the Perpetua program itself and whose release step can be moved to another operator or a threshold network later without re-encrypting share A.

A keeper service checks every switch every 15 minutes. When one is executable it sends the steps: trigger, then settle each asset, then deliver to each heir. Each step is checked against fresh onchain state, so a retried or duplicated step is harmless.

Every execution instruction is permissionless. If our keeper were offline, anyone could run execution with the open-source client, and the program would produce exactly the same result. The keeper pays the network fees and the rent for heirs' new token accounts. Its health is public on Status, and every step is listed on the Ledger.

If an asset can no longer be delivered (the account was closed, emptied, frozen, or its approval was given to another app), the program marks it skipped and delivers the rest. An asset that still fails for any other reason can be skipped after 30 days so the switch can finish.

Fees are taken by the program itself: the 0.05 SOL setup fee for Free-tier switches is moved by the create instruction, and the 0.5% execution fee by the settle instruction, both into a treasury account controlled by the program. You never sign a plain transfer to one of our wallets.

Only the buyback engine key can move funds out of the treasury. Every 15 minutes it swaps treasury SOL for $PERPETUA through Jupiter with a slippage limit and burns what it buys. Each sweep, purchase and burn is on the Ledger.

The admin key can do exactly four things, and nothing else:

• Pause the creation of new switches. Check-ins, edits, cancels and execution never pause.
• Set the buyback engine key.
• Set the $PERPETUA mint for tier checks, once. It cannot be changed afterwards.
• Hand the admin role to another key.

• NFTs: standard SPL and Token-2022 NFTs are supported. Programmable NFTs, Metaplex Core assets and compressed NFTs are not yet supported.
• Token-2022 mints with a transfer hook, non-transferable tokens, confidential transfers or accounts frozen by default are refused when you add them, before any approval is given.
• A token account can have only one delegate. If another app replaces the approval, that asset is skipped at execution. The app warns you when this happens so you can approve it again.
• Up to 12 assets and 16 heirs per switch, so every change fits in one wallet-signed transaction.
• Tiers are checked when you set up or edit a switch, from the $PERPETUA you hold at that moment.

Email support@perpetuaprotocol.xyz. Please include the steps to reproduce, and give us reasonable time to fix the issue before disclosing it. The same contact is embedded in the program and in security.txt.