Trading on Solana
Who signs, who pays, partial fills, and how to know a trade is actually complete.
Solana reference
This chapter covers Solana. For the main Robinhood Chain network, see the Robinhood guide. Wallets, token addresses and settlement mechanics are specific to each network.
Maker, taker, buyer, and seller
The maker posts an order. The taker chooses to fill it. For an ask, the maker sells and the taker buys. For a bid, the maker buys and the taker sells. The buyer always pays the trading fee; the taker pays the wallet-held settlement transaction fee and any required new token-account rent.
You cannot fill your own order with the same wallet. A launcher can trade through a different counterparty and still receive the market’s configured fee, but nominal fee records may differ from net cash flow when a recipient is also a trading party.
Review before approving
Select Buy [token] on a selling offer, or Sell [token] on an offer from someone who wants to buy. Enter a fill quantity up to the available remainder; partial fills are supported. Verify the exact mint, quote currency, unit price, remaining quantity, expiry, settlement mode, buyer debit, seller proceeds, fee recipients, and estimated network costs.
The reference-price label is context, not a minimum output promise from a DEX router. Wallet-held settlement uses the agreed fixed price. Tiny fills can be rejected because the quote amount is below the supported minimum. For a funded order, a competing fill can change its on-chain filled cursor; refresh and prepare a new transaction if that happens.
Quantity and unit price use the gross tokens the seller sends. For a fee-bearing token, review three base-token amounts: seller sends, token transfer fee and buyer receives. A 1% token fee on 1,000 tokens leaves 990 for the buyer, before any cap applies. This token fee is separate from Sidelot’s SOL/USDC trading fee. The final trade page shows amounts from the exact prepared transaction, which can differ from an earlier listing preview.
Wallet-held fill: two approvals
- The taker reviews and prepares the fill. Sidelot reserves that order for the active attempt and constructs one transaction containing all transfers.
- The taker signs the prepared transaction. The wallet prompt may contain multiple transfers and account-creation instructions because both assets and fees settle together.
- The maker opens the trade from their activity, reviews the same transaction and signs it before its blockhash expires.
- The fully signed transaction is submitted to Solana. Both transfer legs and the fee transfers must succeed together.
- Sidelot waits for a successful finalized receipt matching the agreed transaction message before recording completion and releasing any unfilled order remainder.
The maker must be available for this path. Keep the trade page open and share its link when coordinating, but never share signing secrets. If either party declines before submission, no transfer has settled.
- 01Review the fixed terms
- 02Taker signs
- 03Maker signs the same transaction
- 04Submit to Solana
- 05Verify finalized receipt
Reading trade status
A wallet notification or returned transaction signature is not, by itself, evidence of a completed trade. Use the trade page’s final state and explorer receipt.
| State or situation | Meaning and next action |
|---|---|
| Awaiting approval | One or both signatures are still required. Open the trade with the correct wallet. |
| Submitted / confirming | The transaction has been sent or observed; wait for finalized verification. Do not start an accidental replacement payment. |
| Completed | Sidelot verified successful finalized execution and a matching transaction message. |
| Failed | A failure was observed. Transfers in a failed transaction do not partially settle, but network fees may still be charged. |
| Expired | The relevant order time or transaction validity has elapsed. These are different clocks; wait for reconciliation before reusing reserved funds. |
| Refresh needed | A price, order remainder, transaction status or RPC response may be stale. Refresh the trade rather than assuming it failed. |
Two different kinds of expiry
An order expiry controls whether a new fill may be prepared. A transaction expiry comes from its recent blockhash and last valid block height. A transaction already signed before the listing expires is not revoked merely because the listing’s time has elapsed.
Sidelot checks signature status and block-height validity while reconciling an attempt. If a transaction is still potentially valid, the application must not make the reserved order available for an overlapping fill. If the blockhash expired without a successful settlement, refresh the order and prepare a new attempt with new approvals. Do not manually repeat transfers to compensate for an uncertain status.
Funded fill: maker funded in advance
When funded escrow is activated, the maker signs the initial deposit. A later taker signs a fill transaction that moves the taker’s side, releases the escrowed assets, routes fees, and updates on-chain counters atomically. The maker does not sign that fill or need to be online.
The program rejects a changed filled cursor, an excessive quantity, an expired or closed order, invalid account substitutions, or a debit above the prepared limit. See funded escrow and the contract reference for custody and refund rules.