Solana funded escrow
How funded standing orders hold assets, fill offline, and return the unfilled balance.
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.
Implemented, awaiting activation
Sidelot includes a custom Solana Rust escrow program for standing funded asks and bids using original SPL tokens. Token-2022 tokens are not supported by this escrow program, even when they are supported for wallet-held trading. Funded mode is not activated on mainnet in this release. No public Sidelot escrow program address is assigned in the reference source. Check Product status and the program registry before using it.
The following explains the implemented flow and on-chain rules. It is not an instruction to send assets to a guessed address. A local test program address, the platform fee wallet, and the USDC mint are not escrow deposit addresses.
Market activation and order funding
When the configured escrow program is available, the market owner first approves an activation transaction. This initializes an on-chain market account binding the launcher, base mint, decimals and fee recipient. Registering a market through the public API does not perform this transaction.
The maker then creates a funded order and approves its deposit transaction. The program records a fixed original quantity, total quote entitlement, side, quote currency and on-chain expiry. It checks the correct mint, account derivations, signers and required deposit atomically. An order is not funded merely because a pending database entry exists.
On-chain terms cannot be repriced through the wallet-held edit route. Cancel the remaining funded order and create another to change its price or other terms.
Where the deposit goes
Each order has its own deterministic accounts. No shared Sidelot treasury is used as the trading escrow. The account address derives from the program ID and the relevant market/order seed.
| Order | Deposit | Custody |
|---|---|---|
| Ask: sell base token for SOL or USDC | Full base-token quantity | An SPL token vault at a PDA; the order PDA is its token authority. |
| Bid: buy base token with USDC | Full USDC quote amount plus full-order buyer fee | An SPL USDC vault at a PDA; the order PDA is its token authority. |
| Bid: buy base token with native SOL | Full SOL quote amount plus full-order buyer fee | Lamports in the program-owned order account, above its retained rent reserve. |
Fills without a new maker signature
The maker’s funded order authorizes later execution under its fixed terms. A taker can fill part or all of the remaining quantity without the maker being online. The taker signs a transaction containing their transfer and the escrow program’s fill instruction.
The instruction includes the requested quantity, an expected filled-quantity cursor and a maximum nominal gross buyer debit. If someone else filled first, the cursor changes and the stale transaction is rejected. The program also checks open state, on-chain expiry, quantity bounds, positive quote entitlement, mint/account identities and fee recipients.
On an ask, base tokens leave the vault and the taker pays the seller and fees. On a bid, the taker sends base tokens to the maker and deposited quote funds pay the seller and fees. All transfers and progress counters update atomically. Network fees can still apply to a rejected transaction.
- 01Maker deposits once
- 02Order is open on-chain
- 03Taker reviews and signs
- 04Program exchanges assets and routes fees
- 05Remaining quantity stays funded
Partial fills conserve the deposit
The price is represented by the original total quote amount divided by the original base quantity, both in integer base units. For each fill, the program computes cumulative quote and fee entitlements at the new filled quantity, then subtracts what has already been paid.
That approach avoids charging a fresh rounded full fee independently for every tiny partition. The sum of valid fills matches the full-order quote and fee budget. Unused principal and unused fee budget return on cancellation or expiry refund. A fill that creates a positive base-token remainder with zero quote entitlement is rejected. The exact formulas are in contract arithmetic.
Cancellation, expiry, and recovery
The maker may sign Cancel / reclaim to return the remaining inventory or quote balance. Refunds go only to the stored maker and the correct mint account; the caller cannot redirect them. Unsolicited vault donations are returned to the maker as well.
Expiry stops new fills when the on-chain Clock reaches the recorded time. Expiry does not automatically send a refund. A refund transaction is still required. The program includes a permissionless Expire instruction that anyone can submit after expiry, but all funds still return to the maker. The current website exposes maker cancel/reclaim, not a separate permissionless-expiry interface.
A filled token vault is not automatically closed. The maker can use cancel/reclaim after completion to recover remaining donations and token-vault rent without reopening the order. The order account remains as a terminal record to prevent reuse of its identity. Market and order state rent remain allocated.
Freeze and availability limits
Original SPL issuers may retain freeze authority. If a deposited token or USDC account is frozen, transfer or refund instructions can fail until the issuer thaws it. The escrow program cannot override that authority.
The application retains each existing order’s original program and cluster so disabling new deposits or configuring a later program does not intentionally reroute old deposits. Recovery still depends on the original program remaining executable and usable, the chain being available, and the token accounts allowing transfers. Program upgrades and source verification are separate trust considerations; see security.