Security model
Circulate minimizes signer power, pins every server-side operation to Solana mainnet, validates external service origins, and makes reward rounds reproducible from public inputs.
Circulate never asks for a seed phrase or private key. The launcher signs inside the wallet, and the backend rejects a returned Pump.fun transaction unless the connected wallet is a required signer.
Threat controls
| Risk | Control |
|---|---|
| Wrong cluster | Exact mainnet-beta setting plus genesis-hash verification against the configured RPC |
| Unexpected Pump endpoint | Server-side origin allowlist for transaction construction |
| Altered launch transaction | Returned mint parsing and required-wallet-signer verification before wallet approval |
| Keeper key compromise | Low-balance gas wallet, narrow program instructions, vault ownership checks, and amount caps |
| Malicious swap route | Approved Jupiter program, trusted API origin, exact input/output mints, slippage, minimum output, and price-impact limits |
| Snapshot error | Finalized-slot freshness, duplicate consolidation, exclusions, exact allocation, and published Merkle evidence |
| Duplicate execution | Round state, database leases, swap recovery, and per-wallet claim PDAs |
| Upgrade abuse | Reproducible program builds, multisig governance, documented quorum, and public deployment records |
Secret handling
- Keep Pinata, private RPC, database, keeper, and authority credentials in protected server-only variables.
- Expose only browser-safe values with the
NEXT_PUBLIC_prefix. - Use separate wallets for launcher activity, keeper gas, and program governance.
- Fund the keeper only to the level required for expected transaction volume.
- Never place seed phrases in source code, browser storage, databases, logs, support messages, or deployment variables.
Monitoring and auditability
Operators should alert on missed intervals, fee-vault drift, low keeper SOL, route rejection, abnormal slippage, stale snapshots, incomplete batches, and repeated failures. Each round’s inputs, entitlement file, root, and signatures provide the evidence needed for independent reconciliation.
The entity committing a holder root influences allocation. Publishing the complete entitlement set and calculation version, monitoring the committed root, and using independent verification or multisig approval reduce that trust.