Solana wallet-held swaps

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.

An off-chain order and an atomic transaction

Wallet-held mode combines an application listing with a regular Solana transaction. Posting an offer authorizes the listing; it does not transfer the maker’s assets into a vault. The maker retains custody and must approve each accepted fill.

There is no separate Sidelot swap-program deployment for this path, and the builder does not route the trade through Jupiter, Raydium or another AMM. It uses Solana’s existing System, original SPL Token or Token-2022, Associated Token Account and Memo programs. The base mint determines which token program and associated token accounts are used. Both wallets sign the same serialized transaction message.

Solana executes the instructions in a transaction atomically. If a transfer or another instruction fails, its state changes revert together. Network fees may still be charged. This atomicity protects the exchange from one transfer leg succeeding alone; it does not guarantee that the trade will execute or that the token is safe.

What the transaction contains

The transaction starts with a public Sidelot settlement identifier in a Memo. It creates missing destination associated token accounts with idempotent ATA instructions when required. It then transfers the base token from the seller, the agreed SOL or USDC amount from the buyer to the seller, and the two buyer-paid fee shares.

Tokens without transfer fees use TransferChecked under their token program. Fee-bearing Token-2022 base tokens use TransferCheckedWithFee, which also checks the exact expected fee against the fee applicable at execution. A mismatch fails the atomic exchange; network fees may still be charged. The seller sends the gross quantity, and the buyer receives that quantity minus the token fee. Native SOL quote payments use System Program transfers. USDC payments use the original SPL Token Program and the canonical mainnet USDC mint. The taker is the transaction fee payer.

The Memo is a public reference for correlating a receipt. It neither holds assets nor sets prices and is not a substitute for verifying the actual transaction instructions. See program addresses.

1. 01Seller’s base tokens → buyer
2. 02Buyer’s quote payment → seller
3. 03Buyer’s market fee → recipient
4. 04Buyer’s platform fee → Sidelot

Validation and reservations

Before preparation, Sidelot checks the mint and stored decimals, order status and expiry, expected price and revision, fill quantity, and self-fill restrictions. It checks token accounts for the expected token program, owner and mint, sufficient balance, and frozen status. Token-2022 mints may use MetadataPointer, TokenMetadata and TransferFeeConfig. Token accounts may use ImmutableOwner, with TransferFeeAmount required for mints with TransferFeeConfig. Other extensions are rejected. It estimates rent for the token-account layout being created and the transaction fee.

The server reserves the open order using a conditional database update at the expected revision and remaining quantity. That reservation coordinates competing attempts in the application; it does not lock the assets on-chain. Balances or account state can still change before execution.

A partial fill cannot exceed the remaining quantity or leave a remainder below the supported trade minimum. If the price or revision changed after you opened the offer, refresh and review the updated terms instead of reusing an old signing request.

For a fee-bearing mint, preparation selects the fee for the current epoch and calculates gross tokens sent, token fee and net tokens received. A future schedule is shown as a preview. The prepared receipt is decoded from the transaction itself and stays fixed while awaiting signatures. If the applicable fee changes before execution, the expected-fee check can fail; refresh and approve a newly prepared trade rather than altering a signed transaction.

Both signatures must approve identical bytes

The taker signs first. The maker signs the same prepared transaction afterward. When a signed transaction comes back, the server compares its serialized message with the original agreed message, verifies that participant’s Ed25519 signature, checks the active reservation and signing window, and merges only that valid signature.

Changing a recipient, amount, mint, blockhash or instruction changes the signed message and is rejected. Once both required signatures verify, Sidelot submits the transaction with preflight enabled. A valid fully signed transaction is potentially executable until its validity ends; closing a tab, disconnecting or changing a database label cannot cryptographically revoke it.

When the application records completion

The server asks for finalized transaction evidence. It checks that the receipt has no execution error and that its message matches the agreed transaction. Only then does it record a completed attempt and adjust the order’s remaining quantity.

A pending valid signed transaction may be rebroadcast. To release an expired reservation, reconciliation uses finalized block-height and blockhash evidence together with the absence of a successful signature status or receipt. This is why an uncertain trade can remain reserved while the application checks the chain.

The transaction’s network validity and the listing’s expiry are different. Review filling a trade before preparing a replacement. If the application is unavailable, a previously signed transaction can still land on-chain; use its explorer receipt and return to the trade page for reconciliation.

What this mode does and does not secure

Assets stay in participant wallets until the transaction executes, avoiding a standing escrow deposit. Both parties must nevertheless be available to approve each fill. Offers are not guaranteed to be funded, and token issuers may freeze supported SPL accounts.

The application and RPC are needed to coordinate and report the flow. Verify the transaction itself in your wallet, rather than trusting a logo or page label. Read security and trust for the distinction between transaction guarantees, application checks, token authority and contract deployment assurance.