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.

A swap action never rests. SEND keeps no order book, and once an action is queued it 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.

What can wait is the thing that creates actions. A campaign is a standing instruction that queues swap actions on its own schedule, and one of them -- the swap wall -- waits on a price. A wall holds a direction, a target and a budget, and a worker queues one more swap action each time it re-checks and finds the market past that target. Price-conditional execution therefore does exist on SEND: it exists as a campaign rather than as an order type, and there is no interface for it in the app.

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: a price or market-cap target that queues one more swap every time a worker re-checks and finds the market past it, sized either by a compounding ladder or from live pool reserves. There is no interface for it in the app, but its routes are live -- POST /api/v1/walls, then start, cancel, list and a per-wall transaction ledger -- so it is reachable from your own integration. See the Swaps API reference for the full surface

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