BASKET DOCUMENTATION · SOLANA
One token. Up to six underlying coins.
BASKET is a Solana launchpad for tokens backed by a fixed recipe of eligible coins. This interface is configured for Solana mainnet. Read the current deployment status before integrating or submitting a transaction.
What a basket is
A creator chooses one to six coins and their initial weights. The first purchase creates a separate SPL token and acquires the underlying coins into program-controlled reserve vaults. Later buys add the fixed recipe quantities; sells release those quantities and route them back to SOL.
The starting weights define the initial recipe. The protocol does not rebalance the vaults to restore those percentages when prices move. A basket is a custom market, not an index fund, a promise of redemption at a displayed net asset value, or a Pump.fun-issued coin.
Two sources of price movement
The BASKET market curve responds to basket purchases and sales. The SOL value of the underlying reserve also changes with its coins. Liquidity, venue fees and slippage affect executable results in both directions.
Eligible underlying coins
The adapters support eligible native-SOL pairs on Pump.fun, PumpSwap, Raydium CPMM, Raydium CLMM and LaunchLab. Eligibility comes from current on-chain program ownership, pool relationships, token authorities, extensions, liquidity and required fee accounts. A launchpad logo alone is not proof of support.
LaunchLab pools must use the supported CPMM migration path. StonkFun, Robinhood Chain, legacy Raydium AMM v4, non-SOL quote pairs and transfer-tax or transfer-hook tokens are outside the current product scope. An underlying migration can temporarily remove a valid route until the supported destination is available.
Creation and preparation
On basketlaunch.fun, Privy is the default self-custodial Solana wallet provider. Email or Google login creates an embedded wallet, and the explicit Create, Buy or Sell click signs the already-reviewed transaction without a second extension approval. Phantom, Solflare, MetaMask Solana and other detected Wallet Standard wallets remain available as fallbacks. A profile stays linked to one public wallet address, so an external fallback for an existing profile must control that same address.
- Choose terms. Select the coins, weights, identity, creator/cashback allocation and a positive first buy. An account with a verified wallet is required on this website.
- Verify and quote. The client reads fresh venue state, calculates the complete route, checks account and byte limits, and displays first-buy SOL, protocol fees, rent and network fees.
- Check capacity. The complete creation must fit one Solana transaction. Missing accounts are created inside it and paid by the creator. Combinations requiring advance lookup-table preparation are rejected before the wallet opens, so neither BASKET nor the creator prepays an abandoned launch.
- Create and buy atomically. A first buy of at least 0.10 SOL is required. One wallet transaction creates the Token-2022 mint, market, fixed-supply vault and buyer token account; buys every constituent; fixes the recipe; records fees; transfers the first basket tokens from the 1 billion supply; publishes immutable Metaplex identity; and permanently revokes mint authority. If any instruction fails, the whole launch rolls back.
- Index the result. On basketlaunch.fun, artwork and JSON are pinned by BASKET before signing. Third-party launchers publish through their own IPFS, Arweave or Irys provider and pass the resulting immutable URI plus the exact JSON hash. After finalization, the catalog verifies the Token-2022 supply, reserve accounts, on-chain metadata hash, immutable Metaplex record and exact metadata bytes. No backend-funded transaction is required.
Every accepted launch needs one explicit creator action and one cryptographic wallet signature. Privy embedded-wallet signing does not add a separate wallet-extension confirmation screen. Unsupported or oversized combinations stop before signing. A submitted Solana transaction can still consume its network fee if it fails.
Curve and token supply
A composite quote unit represents fixed atomic quantities of all underlying coins. The launch curve starts with virtual reserves of 1.073 billion basket-token units and 30 composite units, with at most 793.1 million basket-token units available through the launch phase. Basket tokens use six decimals.
The constant-product calculation runs in basket-token and composite units. The router separately calculates the SOL required to acquire the composite quantities through current underlying venues. Use integer arithmetic and the program’s rounding rules; a displayed reserve value is not an executable quote.
New basket mints use Token-2022. Activation mints exactly 1 billion tokens once into the program-controlled supply vault. Buys transfer tokens from that vault to traders, and sells return them to the vault. The freeze authority is always absent, and the final instruction in the same launch transaction publishes immutable metadata and permanently revokes mint authority. Client and indexer checks require the supply to remain 1 billion and the supply-vault balance plus circulating tokens to remain exactly 1 billion.
Each accepted creation, basket purchase or sale asks the user for one transaction signature. A first buy creates the trader’s basket-token account in that transaction, with its rent paid by the trader. Routes that require advance preparation are rejected before signing.
Graduation keeps the coin backing
The final launch-curve purchase switches the same market to a permanent BASKET-managed pool in that transaction. It preserves the constituent vaults and fixed recipe and initializes physical reserves at the final marginal curve price within atomic rounding precision.
Graduation does not sell the backing for SOL, create a conventional token/SOL pool, issue an LP token, or give an administrator a reserve-withdrawal instruction. Trading continues through BASKET buy and sell instructions. Basket graduation and an underlying coin’s own launchpad migration are separate events.
Program-enforced fees
Basket buys and sells charge a total BASKET fee of 1% in SOL: 0.70% to the platform and 0.30% divided between creator fees and the trading user’s cashback. The creator chooses that second split at activation and it remains fixed for the basket.
Integer rounding is explicit: total = floor(gross × 100 / 10,000); platform = floor(gross × 70 / 10,000); creator = floor((total − platform) × creatorShareBps / 10,000); cashback receives the remainder. Buy fees use requested SOL input. Sell fees use realized gross SOL proceeds.
Fee liabilities are stored in the market and backed by SOL in its router. Creator and cashback balances are claimable by the entitled wallet from its profile. New-buy pauses do not disable supported sells or claims. Claims require a wallet signature and a network fee.
Standalone supported-coin trades made through BASKET charge a separate 1% platform fee. Underlying swaps inside a basket trade do not pay that second direct-trade fee. Underlying venue and network fees remain separate. Token transfers and unrelated external pools do not automatically pay BASKET fees.
Integrate the protocol
Install the pinned @basketlaunch/sdk v0.2.3 release with npm install https://github.com/BasketLaunch/basket-public-docs/releases/download/v0.3.2-compact-metadata/basketlaunch-sdk-0.2.3.tgz. Use the public integration repository and the Anchor IDL to pin the release. Program address: 149WKoc5878Sx5EWjHGhPBL4vsoogY9og7ffkzdu39LM.
- Pin a release. Call
verifyDeploymentwhen the adapter starts. It verifies the mainnet genesis, program address, ProgramData hash and retained upgrade authority. Read the current config and pause flag before each quote. - Read canonical state. Derive the config, market, router, cashback and constituent vault addresses. Validate the mint supply and authority against the market. The public
readBasketReservehelper returns each constituent mint, initial weight, fixed recipe quantity, canonical vault, token program and current vault balance from one verified snapshot. - Read fresh venues. Validate pool ownership, mints, vaults, fee accounts and CLMM tick arrays for each constituent. Refresh after migrations or material slot changes.
- Quote with exact integers. Apply curve math, recipe rounding, venue costs, the BASKET fee and user slippage. Include account rent and network fees separately.
- Build and simulate one transaction. Call
prepareBasketLaunch,prepareBasketBuyorprepareBasketSellwith the platform’s existing Pump/Raydium route adapter. The SDK checks route order, slots, reserve coverage and signers, applies exact integer limits, and simulates the complete v1 message. Integrators host their own artwork and metadata through a supported immutable provider and pass its URI and exact JSON hash. The SDK contains no BASKET upload service. Standalone coins usedirect_buy/direct_sell. - Check v1 capacity. Creation uses Solana transaction v1: up to 4,096 bytes, 64 inline addresses and no address lookup tables. The SDK compiles and simulates the exact complete message, including missing creator-paid accounts, before opening the wallet.
- Simulate and sign. Simulate the exact complete message, show all costs, verify wallet-returned bytes and signatures, and submit once. Persist the signature before broadcast.
- Reconcile and index. Treat timeouts as unknown. Check historical signature status and finalized expiry before rebuilding. Decode finalized events with the matching IDL and deduplicate by signature plus event position.
Calling BASKET instructions keeps the configured fee routing on chain. An integrator cannot replace the protocol treasury through an instruction argument. The SDK contains no BASKET signer or funded relay; the integrating creator or trader pays rent and network fees. Website accounts, storage and private backend endpoints are separate from the permissionless Solana interface.
Trading-platform adapter
A terminal such as Axiom can discover BASKET markets, chart finalized events and construct its own buy, sell and claim transactions. This is an integration example, not a claim that Axiom currently supports BASKET.
- Index verified BASKET markets and immutable identity. Read the component mints, weights, fixed recipe quantities, vault addresses and live balances directly from the market and reserve accounts; never identify a market from ticker or artwork alone.
- Build candles from finalized executions using actual SOL after refunds. Separate basket volume from direct-coin volume and setup rent.
- Quote the basket curve and every underlying venue from a consistent recent snapshot.
- Supply the exact ordered remaining accounts for the selected adapters, simulate the full atomic route and request one trader signature.
- Expose creator and cashback claims and keep sells available when new buys are paused.
See the trading-platform guide. Contact BASKET on X to coordinate release compatibility.
Verification and control
The deployed treasury, pause authority and upgrade authority is 3ccaGRyZ9fHTRzzH479rzMnmAeME9fWajjuTEvXmCYVc. Upgrade authority is retained, so integrators must revalidate bytecode and IDL after a release. A matching hash identifies deployed bytes; it is not an independent audit.
The candidate release passed full local lifecycle tests through four Pump, six LaunchLab and six Raydium CPMM constituents. A finalized public-devnet five-coin launch used one v1 transaction, one required signature, 52 accounts, no lookup table and creator-funded rent; all five reserve balances, fixed supply and fee liabilities verified afterward. Controlled tests cannot guarantee every future external venue state, wallet implementation or mainnet result. No independent audit is currently published.
Limits and failure handling
Six coins is the current product maximum, but the exact supported count depends on the selected routes. Solana transaction v1 allows 4,096 serialized bytes and 64 inline addresses, no address lookup tables, and a 64-instruction execution trace. The verified envelope reaches four Pump constituents, six LaunchLab constituents and six homogeneous Raydium CPMM constituents. Mixed routes and CLMM routes can reach their limit earlier. The client and official SDK compile and simulate the exact message before signing.
The on-chain state format reserves eight component slots for a future release. Eight-coin creation is not advertised or accepted by this release because no complete eight-coin route has passed the current network limits. A direct caller cannot bypass Solana's account, byte or instruction-trace checks; any failure rolls the transaction back atomically and cannot debit a BASKET infrastructure wallet.
BASKET does not fund new per-launch setup. Accepted routes create missing accounts inside the single user-paid financial transaction; routes requiring advance preparation are rejected. This prevents abandoned drafts from consuming either platform or creator setup funds. The final creation and first purchase remain atomic: if either fails, no basket assets move. Solana network fees are nonrefundable.
Uploads use a durable queue with two processors and up to 1,000 waiting jobs. Each account can have four active jobs and 100 distinct uploads in a rolling day. Artwork is limited to 100 KiB and metadata to 16 KiB. RPC, IPFS providers, Solana congestion and venue liquidity remain separate capacity limits.
