Order Types and Execution

One Execution Primitive

SEND has exactly one trade primitive: an immediate on-chain swap in one of two directions. Every trade you place -- by hand, or through an automation -- is queued as a swap action whose direction is either buy (SOL into token) or sell (token back into SOL). There is no third direction and no order-type field anywhere in the request.

Nothing rests. SEND does not keep an order book, and no price you enter will cause a trade to fire later. An action is executed as soon as the swap executor claims it, at whatever price the pool gives at that moment, bounded only by your slippage tolerance.

The Request a Trade Becomes

Every manual trade -- from the Buy/Sell modal or from the chart trading panel -- is a single POST to /api/v1/swaps. The body carries the project, the direction, the token mint, and one allocation per wallet:

• projectId -- the project whose pool the swap routes through
• actionType -- "buy" or "sell", the only direction discriminator that exists
• tokenMint -- base58 mint address; a malformed value is rejected before anything is queued
• allocations -- an array of { walletId, amountIn }, one entry per participating wallet
• amountIn -- a raw integer: lamports on a buy, raw token base units on a sell
• slippageBps -- optional; the server defaults it to 300 (3%) and rejects anything outside 1-5000

Campaign Types

Every queued swap action carries a campaign type recording which system created it. All four run through the same executor and the same on-chain path; only the scheduler differs.

• manual -- you clicked Buy or Sell. Scheduled for immediate execution
• aging -- a wallet aging campaign, which spreads randomised buy/hold/sell rounds across a wallet set over hours or days
• volume -- a volume campaign, which schedules buy and sell rounds against an hourly plan to reach a target traded volume
• wall -- a swap wall. The backend routes and worker exist, but there is no interface for it today, so no user can create one

The Lifecycle of an Action

Internally a queued action moves through five states: pending, then executing once the worker claims it, then one of completed, failed, or cancelled. You are shown a value from that set exactly once. Every action on the 201 response to POST /api/v1/swaps is reported at status "pending", because the response is written before the executor has claimed anything.

The batch read speaks a narrower vocabulary of its own. GET /api/v1/swaps?batchId= returns one row per submitted action, and its status is "executing" while the swap is in flight, then "success" or "failed" -- three values, of which the last two are the terminal set. "pending", "cancelled" and "completed" never appear on that read. Do not write a client that polls for "completed": the read says "success" where the queue says "completed", so it would wait forever.

The ledger is written only at a terminal outcome, with a side of buy or sell and a status of success or failed. A swap still in flight therefore appears in the batch read, not in your trade history.

Where Your Trade Routes

You do not choose a venue. Routing is resolved server-side from the project, in strict precedence order:

1. The graduated pool address, if the token has graduated, with the venue read from stored pool data
2. The launch pool address, for projects launched directly onto an AMM, using the venue the launch pipeline persisted alongside it
3. The bonding curve pool address, which always routes as pump.fun
4. None of the above -- the request is rejected with "project has no pool address; set graduated_pool_address, launch_pool_address or bonding_curve_pool_address before swapping"

What a Trade Costs

There is no per-trade platform fee. Buying and selling costs Solana network fees only -- the signature fee, priority fee headroom, and, on a first buy, the rent for the wallet's token account.

SEND charges exactly four kinds of fee, none of which is levied per swap:

• wallet_aging_fee -- charged for a wallet aging campaign
• volume_generation_fee -- charged for a volume campaign
• project_launching_fee -- charged for launching a project
• pnl_fee -- charged on withdrawal, against cumulative profit and loss