Skip to main content

Protocol guide · version 2026-08-27.1

How PumpBasket works

Implemented rules, formulas, trust boundaries and known limits. Mainnet financial activation remains blocked; a website deployment is not a verified program deployment.

What PumpBasket is—and is not

PumpBasket is software for isolated Solana token baskets. It is not a brokerage, insured bank deposit, ETF, legal entitlement to conventional shares, or promise of investment returns. The current website is a preview: mainnet transaction activation has not been approved.

Indexes and managed funds

Indexes require 2–8 approved assets with weights totaling 10,000 bps; beta configuration can be smaller. Their seeded asset set and weights are immutable. Managed funds start in approved USDC/cash and can propose delayed changes. Public active funds remain disabled. Managed asset-membership changes are not exposed by the current client because their completion state machine remains unfinished. Wallet allowlists restrict entry, not visibility of public on-chain balances.

Isolated vaults and shares

Each basket has a canonical vault-authority PDA, one ATA per holding, and a Token-2022 share mint. No API owns a user-fund signing key. The program has no manager withdrawal or arbitrary vault-transfer instruction. Upgrade authority can nevertheless change code, so this is not an unqualified trustless system. The fixed seed mints 1,000,000,000 atomic shares; 1,000 remain permanently locked, not burned.

Exact proportional math

Let S be verified mint supply minus locked minimum-liquidity shares and Vᵢ the actual vault balance, including donations. For gross requested shares x: requiredᵢ = ceil(x × Vᵢ / S). For burned shares b: outputᵢ = floor(b × Vᵢ / S). Integer accounting uses checked u128 intermediates on-chain and bigint in the SDK. Every required output must be nonzero. Maximum inputs/minimum outputs and deadlines are enforced atomically. No USD oracle determines normal issuance.

Worked example—illustrative, not live market data

If S = 10,000 atomic shares and vault balances are 1,000,000 and 2,000,000 atomic tokens, minting x = 100 gross shares requires 10,000 and 20,000 tokens. At a 2% deposit fee, 2 shares are fees: with a 50% protocol split, 1 goes to the creator, 1 to treasury, and 98 to the depositor. Burning b = 100 before that deposit returns 10,000 and 20,000 tokens. For V = 1,000,001 and S = 10,000, depositing 100 requires 10,001; redeeming 100 returns 10,000. Rounding favors remaining vault backing.

Fee accounting and total costs

Fee shares F = floor(x × creatorFeeBps / 10,000), capped at 5%; protocol shares = floor(F × protocolSplitBps / 10,000); creator shares = F minus protocol shares; depositor receives x minus F. Fees partition gross new shares, not an additional dilution mint. Creation may be disabled, free or charge configured USDC to the exact treasury; future protocol-token burn is disabled. Network/priority fees, swap/provider fees, account rent and metadata storage can also apply. Unused rent estimates are not charged; actual account rent can remain locked. The current keeper incentive is zero. No fixed USD fee or income is promised.

In-kind exit and operational limits

The redeem instruction does not load ProtocolConfig, prices, an access proof or pause bits. Holders can redeem during proposals and protocol pauses. The final circulating holder receives remaining vault quantities; locked shares and open vault accounts remain. Frozen tokens, unavailable Solana/RPC, insufficient fees, and zero-effective rounding can still prevent a transfer. The independent browser path needs direct RPC and a reviewed deployed program. Large transactions may require separately signed ATA/lookup-table setup and fresh preparation.

Jupiter and Pyth boundaries

Jupiter V2 /order and /execute serve ordinary user-owned swaps; /build is for composition/CPI. The implemented wallet route is a narrow, fee-free, one-hop legacy route with existing canonical accounts; unsupported routes fail closed. Native-SOL entry and broad/optimized batching remain unfinished. Each non-atomic swap and subsequent deposit has a separate review/signature; post-redemption conversion occurs only after tokens arrive. Pyth is used for seed weight and constrained rebalance enforcement; oracle failure must not gate in-kind redemption.

Supported token policy

Direct mint accounts and enabled canonical TokenPolicy PDAs are authoritative; names and symbols are not identities. Check mint addresses, token program, decimals, supply, authorities and extensions. Transfer-fee, confidential-transfer, non-transferable holding tokens, permanent delegates, dangerous hooks, default-frozen, rebasing/scaled or pausable behavior is rejected unless separately reviewed. Restricted share mints may themselves be non-transferable. Current vault swaps support legacy SPL holdings only, with two assets per atomic rebalance.

Manager powers and delays

Same-mint guidance/fee decreases wait at least 24 hours; fee increases, asset/access changes at least 48 hours; manager rotation/recovery at least seven days. Longer configured delays apply. An exact canonical target hash, activation and expiration govern execution. Holders can redeem throughout. Index creators have no discretionary index control. Protocol configuration changes wait at least seven days. Manager withdrawals, arbitrary CPI destinations and hidden backend actions are prohibited.

Trust assumptions and authority separation

Governance, emergency authority, treasury, upgrade authority, keeper and deployment identities must be distinct at release. Squads vault authority—not its multisig configuration account—signs governed instructions. API roles are off-chain only. RPC/indexer/database projections may disagree with chain; metadata may be malicious. Keeper keys pay for constrained rebalances, not withdrawals. Multisig member compromise, malicious upgrades and infrastructure censorship remain risks. See deployment evidence and operational runbooks before any activation.

Deployed addresses and audit scope

No mainnet program, deployment slot, independent audit, legal approval, authority roster or incident contact has been approved for this release. A runtime-configured address alone is not deployment evidence.

version
2026-08-27.1
status
blocked
mainnetProgram
Not published / release blocked
deploymentSlot
Not published / release blocked
sourceCommit
Not published / release blocked
binarySha256
Not published / release blocked
idlSha256
Not published / release blocked
independentAudit
Not published / release blocked
legalApproval
Not published / release blocked
governanceMultisig
Not published / release blocked
upgradeMultisig
Not published / release blocked
treasury
Not published / release blocked
emergencyAuthority
Not published / release blocked
keeperAuthority
Not published / release blocked
deploymentAuthority
Not published / release blocked
incidentContact
Not published / release blocked

The repository includes DEPLOYED_ADDRESSES.md, GOVERNANCE.md, KEY_MANAGEMENT.md, INCIDENT_RESPONSE.md, MAINNET_RUNBOOK.md and verified-build instructions in UPGRADE_AND_MIGRATION.md. Hash comparison is not an audit. No deployed binary or source commit is invented here.

Read risks and acknowledgement · Draft terms · Draft privacy notice