Security and trust boundaries
What is enforced by signatures and programs, what depends on the application, and what remains a risk.
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.
Custody depends on the settlement mode
In wallet-held mode, assets stay in the participants’ wallets until a transaction signed by both executes. The application coordinates the order and its reservation. A displayed balance check is a snapshot, not an on-chain asset lock.
In funded mode, the maker deposits assets under the custom program’s rules. The program’s account checks and PDA authority govern fills and refunds; a database row alone cannot authorize a release. Contract bugs, token freezes and any deployment upgrade authority remain relevant risks.
A fee wallet only receives fees routed during settlement. It is not a universal deposit vault. Never transfer tokens to an address merely because someone calls it “Sidelot escrow” in a message.
Verify the token and counterparty
Token names, symbols, logos and market descriptions can be copied. Check the full mint, the market owner, the fee recipient and the links before trading. A holder/team role is self-declared. Registering a listing does not verify a token issuer, guarantee liquidity or endorse the asset.
Supported original SPL and Token-2022 tokens may still have mint authority or freeze authority. A mutable supply or frozen account can affect economic value and trade execution. Freeze authority can also block original SPL escrow withdrawals. Token-2022 support permits MetadataPointer, TokenMetadata and TransferFeeConfig on mints, plus ImmutableOwner on token accounts and required TransferFeeAmount state when the mint has TransferFeeConfig. Other extensions are rejected. Compatibility is not a quality or safety certification.
A transfer-fee configuration authority can schedule changes to the token’s fee. Review the current and scheduled terms and the exact net receipt at settlement. Sidelot’s expected-fee instruction prevents a changed fee from silently changing that approved receipt; it does not guarantee execution or remove network costs from a failed transaction.
Understand what you approve
Message signatures authorize specific application actions. Transaction signatures authorize on-chain instructions. Inspect the mint, quantity, quote, fee recipients, total debit and program identities before signing. Use the official domain and reject requests that ask for a seed phrase or private key.
An already signed valid transaction may be submitted or rebroadcast until its validity ends. Closing the browser, disconnecting, deleting local history or changing the listing expiry does not revoke that cryptographic authorization. Sidelot waits for chain evidence before releasing reserved orders.
Deployment checks are not an audit
Sidelot checks the RPC network and genesis, the executable program and its loader, and the canonical ProgramData account. It reads program accounts at finalized commitment and compares their bytecode with a pinned release’s SHA-256 hash and length; any extra reserved capacity must contain only zero bytes. Mainnet funding and fills also require the release’s expected upgrade authority.
New deposits require escrow to be enabled and to match the configured program and active approved release. Existing orders retain their original program. Their reads, fills and cancellation paths can recognize retained historical release pins. Reads and cancellation do not require the upgrade authority to remain unchanged, so an authority rotation alone does not block recovery; they still require recognized bytecode and valid account state. Turning off new deposits therefore does not, by itself, turn off existing-order recovery.
These checks identify an approved build; they do not prove that its code is correct or independently audited. An upgrade can occur after a check, and unrecognized code or an RPC outage can still prevent the application from preparing a withdrawal. A program with an upgrade authority can change in the future. The reference source has no administrator-withdrawal instruction or market fee-wallet-change instruction, but those are properties of the reviewed source, not a promise about every future upgrade.
No independent security audit or mainnet deployment is established by these checks. See Product status for current activation and review information.
What is public and what the service stores
Solana transactions, wallet addresses, token accounts and balances are public on-chain. Market metadata and the public API’s listings are public. The application stores market/order records, signed authorizations and transaction/operation records needed to coordinate and reconcile trades; uploaded market images are served by the application.
Price and chart data come from DexScreener, and chain reads/submission use the configured Solana RPC provider. A chart or live reference is external data, not an oracle used to settle your fixed-price order. Consult the Privacy policy and Terms for the site’s policies.
Getting help safely
Contact @SidelotOTC. Include the market or trade URL, public transaction signature if one exists, the approximate time and the error text. Those identifiers help distinguish an approval problem, an RPC delay and an executed transaction.
Do not send a wallet password, private key, recovery phrase, session cookie or RPC credential. If the state is uncertain, preserve the trade link and inspect the receipt before preparing another transfer.