Market Orders - SEND Docs

Two Places to Trade

A market order on SEND is an immediate buy or sell of a project's token, split across as many of that project's wallets as you select. Each wallet's leg is an independent on-chain transaction: there is no atomicity between wallets, and a batch can partially fill.

The Buy/Sell modal is the primary surface. Open it from the Buy or Sell button on a project's quick actions, or from a wallet card in the project's Wallets tab, which pre-selects that wallet. Both entry points only appear once the project has a token and is in a tradable state.

The chart trading panel is the second surface. Click Maximize on the project's inline price chart to open the fullscreen chart; the panel sits in the right column. Its top box is always the token and its bottom box is always SOL, both editable and linked by the live price, with BUY and SELL tabs relabelling them.

Wallets and amount -- pick the source wallets and the total, as a percentage or an absolute figure
Distribution -- shown only when more than one wallet is selected: equal, weighted, random, or custom per-wallet amounts
Confirm -- a read-only summary of what will be submitted

Slippage

Slippage is the only execution parameter you can set, and the default differs by surface:

Priority fee, compute budget, and relay choice are not exposed on manual trades -- the swap request carries none of them. Fee ladders and relay tips exist only on the launch path, where they are operator-tuned.

Buy/Sell modal -- fixed at 500 bps (5%). There is no picker; the Confirm step shows the figure read-only
Chart trading panel -- defaults to 100 bps (1%), with 0.5% / 1% / 3% presets. Your choice is remembered in the browser
Sell Dev modal -- defaults to 100 bps (1%), adjustable under Advanced from 10 to 1000 bps with 0.5% / 1% / 2% / 5% presets

Amounts, Maximums, and Floors

On a buy, your SOL figure is converted to lamports and split across the selected wallets. On a sell, your token figure is converted to raw base units using the token's on-chain decimals. If decimals cannot be loaded, the sell is refused rather than guessed -- the chart panel disables the button and says so, because a wrong decimals assumption would size the order wrongly by orders of magnitude.

Max on a buy never spends a wallet down to zero. Each wallet keeps a reserve for network fees and, on a first buy, token-account rent. The two surfaces reserve different amounts on purpose:

Selling a token still costs SOL. A wallet holding tokens but under 0.0002 SOL cannot sell until you send it a little SOL.

Buy/Sell modal -- reserves 0.01 SOL per wallet, sized to cover first-buy token-account rent
Chart trading panel -- reserves 0.004 SOL per wallet
Sell eligibility floor -- a wallet needs at least 0.0002 SOL to execute a sell; below that it is greyed out with the remedy shown
Chart panel presets -- 100K / 500K / 1M / 10M tokens, 0.1 / 0.5 / 1 / 5 SOL, or 25% / 50% / 75% / 100% of balance

What Happens After You Click

Submission queues work; it does not trade. The sequence is:

The progress strip under the Execute button shows four phases: Submitting, then Submitted with the signature, then Confirmed or Failed. Submitted is deliberately NOT a terminal -- the spinner stays until the batch poll (every 2 seconds) proves the outcome. The realtime feed is best-effort; the poll is the guarantee.

The API validates the request, verifies you own every wallet, resolves the pool, and creates one pending action per wallet under a single batchId
A wake signal is published so the executor claims the batch within milliseconds instead of on its next poll; if that signal is lost, the executor's 5-second poll picks it up anyway
The executor claims each action (pending to executing), re-resolves routing against live graduation state, and submits. It returns at signing time with a signature, not with a fill
Manual transactions are tagged with an on-chain memo of the form ck1:<action id>, so a swap whose confirmation timed out can still be found and reconciled from the chain
Terminal state is written only against positive on-chain proof, with a confirmation wait of up to 90 seconds

When It Takes Longer Than Expected

A manual action that does not confirm immediately is retried up to 6 times, 20 seconds apart, and terminal-fails at 300 seconds from creation regardless of retry count.

Every one of those retries is confirmation-only. A manual swap is never automatically re-submitted, because no RPC can prove that a transaction did not land -- and a re-submission of a sell that actually did land would sell twice. If the outcome cannot be established, SEND says so rather than guessing.

The executor processes at most 50 manual actions per tick, so a very large batch drains over several ticks rather than all at once.

Failure Messages

A failed leg carries a tagged, plain-language reason. Quote the tag when contacting support:

CK-UNKNOWN is not a failure. It means the outcome could not be established, and funds may have moved. Verify the wallet balance before you retry that leg -- a blind retry can double a sell.

CK-UNKNOWN -- the swap could not be confirmed. It may have landed; check your wallet before retrying
CK-CHAIN -- the transaction reached the chain and failed on-chain. Use View Tx for the reason
CK-INFRA -- network congestion prevented confirmation after several retries. No funds moved unless a transaction link is shown
CK-SLIP -- price moved beyond your slippage tolerance. Retry with a higher tolerance
CK-FUNDS -- insufficient balance to complete the swap
CK-ERR -- anything else, with a truncated raw error attached for triage

Selling from the Dev Wallet

The dev wallet sells through a separate route, reached from Token > Sell Dev on the project page. Unlike a normal buy or sell, it is synchronous: the request runs to completion and returns the transaction signature, the amount sold, and the amount received inline rather than queueing a batch.

You choose a percentage of the dev wallet's holding -- 25%, 50%, 75%, 100%, or any value on the slider, defaulting to 25% -- plus an optional slippage override.