buy instruction purchases tokens from an active RugFreePump bonding-curve sale using SOL.
The instruction accepts a gross SOL amount, deducts the configured protocol fee, denominates the remaining SOL contribution in USD-equivalent terms using a validated Pyth SOL/USD price feed, calculates the corresponding token amount using the bonding curve pricing model, and adds the purchased token amount to the buyer’s cumulative token allocation recorded in their on-chain account.
Purchased tokens are not transferred directly to the buyer during the purchase. They become claimable only after successful liquidity migration.
Instruction Execution Requirements
Sale Status
Before constructing abuy transaction, read the following fields from the required accounts and verify that the sale is eligible for purchase:
If the current Unix timestamp is greater than or equal to
sale_expires_at, the program sets is_sale_active to false and rejects the purchase.
Because these values can change between transaction construction and execution, client-side checks should be treated as pre-validation only. The on-chain program performs the authoritative checks when the transaction executes.
Sale Cap and Finalization Buffer
The bonding-curve sale uses fixed-point USD-equivalent values with 2 decimal places for its sale cap and finalization threshold. Buyers contribute SOL, and the value of the SOL contribution after the buy fee is deducted is measured against these limits using the validated SOL/USD price.- Contribution Valuation: The buy fee is deducted from the gross SOL amount first. The remaining SOL amount is then valued in USD-equivalent terms using the validated SOL/USD price.
- Capacity Constraint: The USD-equivalent value of the SOL amount remaining after the buy fee must not exceed the sale’s remaining USD-equivalent capacity.
- Auto-Finalization: After a successful purchase, the sale is finalized when the remaining USD-equivalent capacity falls below
SALE_FINALIZATION_BUFFER_USD_E2.
bonding_curve_pda.total_raised_usd_e2 from MAX_USD_RAISE_CAP_IN_USD_E2.
Minimum and Maximum Purchase Limits
- Minimum Purchase:
MIN_BUY_AMOUNT_IN_USD_E2 = 100, representing 1.00 USD. After the buy fee is deducted, the remaining SOL amount must have a USD-equivalent value of at least 1.00 USD. - Maximum Purchase: There is no separate hard-coded per-purchase maximum. The maximum permitted SOL amount is constrained by the sale’s remaining USD-equivalent capacity, after accounting for the buy fee and the current SOL/USD price.
- Dynamic SOL Limits: The maximum valid SOL purchase amount changes with the sale’s remaining USD-equivalent capacity, the configured buy fee, and the current SOL/USD price.
Buy Fee
Thelamports_amount argument represents the gross SOL purchase amount.
The configured buy fee is deducted from the gross SOL amount before the remaining SOL amount is valued using the SOL/USD price and checked against the minimum purchase and remaining sale capacity.
The current initialized buy fee is 100 bps (1%) and is read from global_states_pda.buy_fee_bps.
The configured fee may change through protocol administration.
Buyer SOL Balance
The buyer must have sufficient SOL to cover the submitted grosslamports_amount.
If buyer_accumulation_pda does not already exist, the buyer also pays the required account creation rent.
The transaction must therefore provide enough SOL for both the gross purchase amount and any required account initialization.
Slippage Protection
Thebuy instruction includes slippage protection based on the bonding-curve state supplied by the caller.
Before constructing the transaction, read the following fields from bonding_curve_pda:
total_raised_usd_e2total_sold_tokens_e6
expected_total_raised_usd_e2expected_total_sold_tokens_e6
slippage_bps specifies the maximum permitted increase in the average price.
If the execution-time increase exceeds slippage_bps, the transaction is rejected.
Because the bonding-curve state can change before execution, these values should be fetched immediately before constructing the transaction.
SOL/USD Price Feed
Thesol_usd_price_feed account must contain a valid Pyth PriceUpdateV2 account for the SOL/USD price feed.
Before the price is used for the purchase calculation, the program validates:
- The Pyth update has
VerificationLevel::Full. - The update corresponds to the Pyth SOL/USD feed ID configured in the RugFreePump program.
- The price update is no older than 60 seconds.
- The reported price is positive.
- The oracle confidence interval does not exceed 2% of the reported price.
buy transaction is rejected.
Pyth SOL/USD Feed ID
Current PriceUpdateV2 Account
PriceUpdateV2 account containing an acceptable update for the same SOL/USD feed, provided it satisfies the program’s validation requirements.
Rust
Instruction Anchor Signature Definition
Instruction Anchor Accounts Definition
Instruction Data
The
expected_total_raised_usd_e2 and expected_total_sold_tokens_e6 values are state snapshots used by the buy instruction’s slippage check logic. Read the current bonding_curve_pda account, derived with seeds [b"bonding-curve", mint], immediately before constructing the transaction.
These values, fetched from the bonding-curve PDA account, are already stored in their required formats and can be passed directly without unit conversion.
Instruction Accounts
The following accounts must be supplied tobuy in the order defined by the instruction.
TypeScript
Transaction Construction
The following example derives the required accounts, reads the currentbonding_curve_pda data account state for slippage protection, constructs the buy instruction, and submits it in a versioned Solana transaction.
RUGFREEPUMP_PROGRAM_ID, IDL, provider, wallet, mint, and SOL_USD_PRICE_FEED_ACCOUNT are application-specific values supplied by the integrating application.
The buyer_accumulation_pda is created automatically by the buy instruction if it does not already exist. The buyer pays the required account rent.