Security

Custody follows the money. Today, every lamport that moves through a Pair Market moves directly between Solana accounts that its owner controls: the trader’s wallet, the Pump programs’ accounts, the creator’s wallet and the PairStreet PairStreet treasuryPairStreet treasuryThe protocol wallet that receives the protocol share and Pair Vault reserve of creator fees plus the 0.5% trading fee.. PairStreet’s servers hold no key with authority over any of them.

The custody model is a column on every Pair Vault (custody_model: program_pda, multisig, provider_custody). A vault holds assets only once its model is deployed for that market’s instrument. Until then the market’s 25% Pair Vault reservePair Vault reserveThe 25% share of a Pair Market's creator fees earmarked for its Pair Vault. Held by the PairStreet treasury until the market's settlement route activates. accrues in the treasury and is accounted per market.

PairStreet deploys no custom onchain program today. It composes existing programs: Pump for creation and trading, the Pump fees program for the creator-fee split, PumpSwap for graduated markets, and the System Program for fee transfers. Upgrade authority for those programs rests with their deployer, not with PairStreet.

Pump program

6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P

Pump fees program

pfeeUxB6jkeY1Hxd7CsFCAjcbHA9rWtchMGdZ6VojVZ

PumpSwap AMM

pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA

Fee-split authority

At launch, the bonding curve’s creator becomes the coin’s fee-sharing config. The creator then sets the shares once: creator 5,000 bps, treasury 5,000 bps. Pump revokes the config’s admin after that update (adminRevoked = true), and from then on no account can change the shares, PairStreet included. A market whose split did not land shows “Split pending” and only its creator can lock it, from the market page.

Future programs

The Pair Vault program and the Merkle distributor for live claims are part of the settlement architecture. Their upgrade authority is designed to sit with a multisig rather than a single key, and both are audited before activation.

• ·Mint keypair. For each launch the server generates the new coin’s mint keypair and pre-signs the creation transaction with it. That key’s only role is to sign the creation of that one mint; the launch session holding it is deleted on confirmation.
• ·Server secrets. The database URL and RPC configuration live in Vercel’s encrypted environment variables. The environment module is server-only and is validated at startup; production refuses to start without a Postgres URL or with a development launch adapter.
• ·Provider credentials. Routes that need credentials (provider API, RFQ, broker) keep them as server secrets behind the provider interface, never in the client bundle. Executing a live acquisition also requires a configured vault signer; providers refuse to purchase without one.
• ·Uploads and metadata. Images are checked by their magic bytes, not their declared type: PNG, JPG, GIF and WEBP up to 4 MB. SVG is rejected. Token metadata JSON is immutable once written and is served at a permanent URI.
• ·Headers. Every response sets X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a strict-origin referrer policy, and a permissions policy that disables camera, microphone and geolocation.

Pause controls

Two status fields act as switches. Both are enforced on the server.

Rate limits

Write endpoints use a per-IP token bucket, per endpoint, refilled continuously. Requests above the budget receive HTTP 429. Request bodies above 64 KB are rejected before parsing, and every body is validated against a schema.

Buckets are held in memory on each server instance. A shared store for rate limits and replay protection, so limits hold across instances, is Planned.

• ·The client simulates every prepared transaction against the network before asking the wallet for a signature. A failed simulation stops the flow; nothing is signed.
• ·Trades carry a minimum output derived from the user’s slippage setting, so a trade that would fill worse than the quote fails onchain instead of filling.
• ·Every transaction carries a recent blockhash and a last valid block height. A transaction that has not landed by then expires; a retry builds a fresh one.
• ·Launch confirmation verifies the signature on chain: the transaction exists, did not fail, contains the expected mint and creator, and the bonding curve exists. Only then is the Pair Market registered.
• ·Claims require a signed wallet intent: a message naming the action, the wallet, a SHA-256 digest of the exact payload and the issue time, verified as an ed25519 signature. Intents expire after five minutes and are single use. On the development network, launch and trade requests are authorized the same way; on mainnet, the wallet’s signature on the transaction itself is the authorization.

recomputeFromLedger rebuilds a market’s Pair aggregates from ledger rows alone; tests assert the stored read model equals it for every market. Blocked settlements are recorded with status failed and their blockers in the error column. Each indexer source writes its last run time, status and last error to indexer_cursors. Server errors are logged with their route. See Accounting.

Alerting on indexer errors and on drift between the ledger and onchain vault balances is part of the vault custody rollout, alongside the public proof page.

Each threat below lists the risk, the mitigation and the assumption that remains. Mitigations marked live are implemented and tested today; mitigations marked architecture are the design that ships with Pair Vault custody and settlement.

Failure handling for each of these cases is covered in Failure Modes. The reward methods referenced here are specified in Holder Rewards.