A direct market for every community.

1. Abstract

Sidelot is a marketplace for community-launched, over-the-counter trades in existing tokens. Robinhood Chain is the main network; Solana remains available as a separate beta integration. A holder or organizer registers a market, chooses its presentation and fee recipient, and gives buyers and sellers a shared place to publish offers. Participants choose a fixed price and quantity; a completed exchange routes a buyer fee between the market recipient and Sidelot.

The architecture separates market discovery, action authorization and transaction coordination from asset transfer. In the existing Solana beta, wallet-held offers use one transaction signed by both traders. A separate, optional escrow program supports funded standing orders that can be filled without another maker signature. That program is implemented and locally tested, but public funded deposits are not activated in this release.

The existing Solana launch API lets authorized applications and AI agents prepare a market registration for its owner to sign. Market creation requires launch-password access for both preparation and commit. Public reads and offer posting/cancellation do not require that password. It does not grant spending authority. This paper explains the Robinhood contract architecture, then preserves the existing Solana implementation as a network-specific reference. Deployment evidence and activation status are stated separately from contract design. The trading interface is in public beta; the Product status page identifies current availability. No independent security audit, guaranteed liquidity or guaranteed financial return is asserted.

2. A community market for an existing coin

Token communities can contain willing buyers and sellers without a convenient way to discover compatible offers or coordinate a direct exchange. Sidelot gives them a persistent market link, visible terms and a shared settlement workflow. A launcher can organize that activity and choose a personal or community fee wallet to receive part of the completed trading fees.

Launching a market is not launching a token. Registration references an existing mint. It does not create supply, change mint or freeze authority, seed a liquidity pool, or grant control of the underlying project. Several independently launched markets may reference the same mint. Market names and symbols are presentation fields; the complete mint address identifies the asset.

An OTC settlement does not route that exchange through a DEX pool. Its execution therefore does not walk that pool’s price curve. This does not mean an OTC trade is invisible, that holders cannot subsequently trade elsewhere, or that the token’s wider price cannot move. Counterparties still have to agree, maintain the necessary funds and complete settlement.

The product’s incentive is straightforward: a useful market attracts willing participants, and completed trades route fees to its designated recipient. Registration, a posted offer, a social announcement or an unfilled order does not itself generate trading fees. A community label does not automatically distribute those fees to every holder.

Robinhood Chain: contract architecture

Robinhood Chain is Sidelot’s main network. Solana continues as a separate beta integration. Users must be able to identify the network, token address, transaction authority and deployment before acting; a network selector must not disguise one runtime as another.

No verified active Robinhood deployment is published in this release. The implementation uses non-upgradeable SidelotMarketRegistry and SidelotExchange contracts, standard ERC-20 tokens, and native ETH or compatible ERC-20 quote assets. Market identity and the configured platform recipient are fixed. An exchange guardian using two-step ownership transfer can pause funding and fills; it cannot seize deposits through an administrative withdrawal. Maker cancellation remains available while paused. Mainnet chain ID is 4663; testnet chain ID is 46630. ETH is the network gas asset. Network availability itself does not establish that Sidelot contracts are deployed there.

Market identity and registration

A market binds an existing token contract to a launcher and fee recipient. Community and solo are presentation and participation choices, not proof of project ownership. An EVM token is identified by its full contract address and chain together. Registration must verify a successful contract receipt before it is represented as a created on-chain market. A Solana mint, Solana fee wallet or database market ID cannot be silently reused as an EVM contract identity.

Wallet-held orders and authorization

The new design uses EIP-712 typed orders with domain name SidelotExchange and version 1, bound to the chain and exchange address. Signature checking includes compatible ERC-1271 wallets; browser wallet support remains a separate concern. The maker reviews the market, token amounts, payment terms, expiry and nonce. A token allowance authorizes a particular spender; the signed order authorizes particular terms. Neither wallet connection nor an AI proposal replaces those approvals. Execution must validate the signature, current order state, remaining quantity and actual transfer results atomically.

Native ETH cannot be pulled from an offline wallet by an ERC-20 allowance. Wallet-held sells can collect ETH from the taker; wallet-held buys require an ERC-20 quote asset and the maker’s allowance and current balance. Funded buys deposit the quote principal and buyer-fee budget in advance. The contract supports ERC-20 quotes, while the interface may support a narrower list. The initial exchange uses explicit token approvals, not permits. Quote and base assets must differ; accepting an address is not an endorsement of its token.

Funded orders and recovery

Funded mode deposits the maker’s required assets into the exchange under the order’s recorded terms. It needs exact accounting for partial fills, fees and remaining refundable balances. Maker cancellation, expiry and competing fills must be enforced by contract state. A cancelled listing is not a completed refund, and a transaction hash is not a successful receipt. Maker cancellation returns remaining base tokens for a sell or unused quote principal plus fee budget for a buy, in one atomic transaction. The maker may select a refund destination; permissionless expiry only refunds the maker. Recovery remains available while the exchange is paused. Native recipients that reject ETH cause the transaction to revert; a maker can retry cancellation to another destination. Any public activation must preserve a usable recovery path for outstanding deposits.

Initial token and fee policy

The initial implementation targets standard ERC-20 transfers. Balance-delta checks are intended to reject fee-on-transfer, rebasing and other unexpected transfer behavior instead of silently delivering less than the signed amount. This is separate from Solana’s supported Token-2022 transfer-fee path; those compatibility results do not certify an EVM token. Balance checks cannot certify a dishonest token contract, and a token that changes tax, pause or blacklist behavior after deposit can obstruct refunds. These contracts are not independently audited; using a standard dependency does not make the complete exchange audited.

The exchange buyer trading fee is 50 basis points, split equally between the market recipient and Sidelot, subject to integer rounding. ETH gas is separate and can be spent on a reverted transaction. Only successfully completed settlement generates trading fees. No market volume, liquidity or earnings are guaranteed.

Activation evidence

Before public deposits or trades, publish verified contract addresses and bytecode, the exact network and constructor configuration, supported token and payment modes, approval requirements and recovery instructions. Exercise registration, both sides of supported trades, partial fills, cancellation, expiry, stale signatures, replay attempts, fee accounting and token failures. Local and testnet results do not constitute an independent audit or confirmed mainnet operation.

The canonical Robinhood Chain chapter, Robinhood workspace and Product status distinguish source implementation from configured, deployed, verified and activated operation. Sidelot is independent; deployment on Robinhood Chain does not imply Robinhood endorsement.

Solana beta: implementation reference

The numbered sections below preserve the mechanics of the existing Solana beta. References to SPL, Token-2022, SOL, USDC, program-derived addresses, account rent and two-party Solana transactions apply to that integration only. The Solana Rust escrow remains a separate implementation and deployment from the Robinhood EVM exchange.

3. Participants, addresses and authority

A maker posts an offer. A taker accepts it. A bid maker buys the token; an ask maker sells it. The taker is therefore not always the buyer. Separating these roles matters because the buyer pays the trading fee while the taker pays network costs for a wallet-held exchange.

A valid public address is not necessarily a wallet that can sign a message. The public API requires an on-curve launcher address and fee-recipient address; it does not accept an arbitrary program-derived treasury address as a signing wallet. Current browser integrations support Phantom and Solflare through injected providers, plus MetaMask’s native Solana Wallet Standard connection in a compatible extension-enabled browser.

Connection exposes a public address. A message signature approves a particular application action. A transaction signature approves on-chain instructions. These approvals are distinct. Neither an AI response nor access to an launch-access session substitutes for the required wallet signatures.

4. Market registration and community identity

Registration records the mint and decimals, launcher, fee recipient, market type, role, name, symbol, description, optional links and image references. A solo market is recorded as holder-led. A community launcher selects holder or team. Team registration requires HTTPS website and social links, but the displayed affiliation remains self-declared. It is not verified identity, official endorsement or exclusivity.

Names contain 2–60 characters, symbols 1–16 and descriptions up to 500. Links are limited to 300 characters and must use HTTPS without embedded credentials. The API rejects unknown fields and normalizes a solo role to holder. Mint inspection accepts initialized original SPL mints and Token-2022 mints with no extensions or only MetadataPointer, TokenMetadata and TransferFeeConfig. Transfer hooks, permanent delegates and all other mint extensions are rejected. Supported Token-2022 markets use wallet-held offers and settlement; the funded escrow program still accepts original SPL tokens only.

The launch form supports optional pictures and banners. PNG, JPEG and WebP inputs are resized and converted before upload, and each upload is authorized against its size and content digest. Stored images belong to the approving wallet. The public API accepts existing owned image IDs; it does not expose a general image-upload endpoint.

The fee recipient is fixed for the market, and the current product has no self-service market-profile or recipient update operation. This is an application constraint for the off-chain registry. When funded escrow is activated, the on-chain market also binds its launcher, mint, decimals and fee wallet, with no fee-wallet-change instruction in the published program.

Registration has no Sidelot listing fee in this release. Signing its authorization does not submit an asset-transfer transaction. One wallet can register up to 50 markets. See Launching markets for field-by-field instructions.

5. Architecture and state ownership

The website and API run on a server application backed by Cloudflare D1 and R2. D1 stores market records, offers, signed-action challenges, transaction attempts, escrow-operation records and rate-limit counters. R2 stores uploaded market images. These are application services, not an on-chain order book.

The application reads Solana through a server-configured RPC endpoint; provider credentials are not sent to the browser. RPC reads support mint validation, balance checks, transaction preparation and finality reconciliation. An RPC interruption can delay the interface’s knowledge of a transaction without changing what already happened on chain.

Database records do not create authority to debit a wallet. In funded mode, a database row cannot release a deposit. Conversely, the wallet-held reservation mechanism is enforced by the application, not by a custom on-chain order account. The two modes have different trust and availability properties and should not be collapsed into one blanket “trustless” claim.

Public addresses, market metadata and blockchain transactions can be observed or indexed. OTC describes how a trade is agreed; it does not provide anonymity or confidentiality. Security documentation explains these boundaries in operational terms.

6. Prices, premiums and market context

An offer contains a gross base-token quantity sent by the seller, SOL or USDC quote currency, expiry and fixed execution price per gross token. Any token transfer fee reduces the buyer’s net received quantity. Remaining order quantity is reduced by gross units settled. A premium or discount is a convenience for calculating that price from a reference:

fixed_price = reference_price × (1 + adjustment_percent / 100)
comparison_percent = (fixed_price / current_reference - 1) × 100

The adjustment is applied when setting the price; the resulting order is not automatically pegged to a moving feed. If a holder posts at 9.50 USDC against a 10.00 USDC reference, it initially displays 5% below market. If the reference later becomes 9.00 USDC, the unchanged offer is approximately 5.56% above market.

Current reference panels use DexScreener. The service selects the highest-liquidity usable indexed Solana pair returned with the requested mint as its base token. SOL and USDC comparisons use their available USD references for conversion rather than assuming USDC always equals one dollar.

The visible page requests updates about every 30 seconds. The server briefly caches data, and references older than 90 seconds or marked stale are excluded from live comparisons. A missing conversion can make a comparison unavailable even when a token USD price is visible. A retained stale value is not presented as a fresh executable quote.

Market cap is provider-reported and is not substituted with fully diluted valuation. Volume and liquidity describe the selected DEX pair, not Sidelot’s order book or every venue combined. The embedded chart has its own update cadence. Comparisons exclude trading fees, network fees and account rent; signed settlement terms remain the authority for the actual exchange.

7. Wallet-held settlement lifecycle

Posting a wallet-held offer stores terms without transferring or locking assets. Bids and asks can be partly filled, have 1-, 3-, 7- or 30-day expiries, and remain dependent on current balances. Editing an open offer changes the remaining price, not its side, quote currency, quantity or expiry.

Preparing and reserving a fill

The taker requests a quantity against the current price and order revision. The server rejects self-fills, expired or unavailable offers, overfills and partial fills that leave an untradeably small remainder. It inspects the mint, checks relevant balances and associated token accounts, and prepares one recent-blockhash transaction.

A conditional database update reserves the order only if its status, revision, remaining amount and expiry still match. The transaction attempt is inserted in the same database batch. A competing request that loses this comparison must refresh rather than using the old terms. While reserved, that order cannot accept another wallet-held fill or be edited through the application.

One message, two transaction signatures

The transaction includes a unique public memo, token delivery, quote payment and both fee transfers. Required destination associated token accounts are created idempotently where needed. The taker is the transaction fee payer. Base-token transfers and associated accounts use the mint’s actual token program. Token-2022 accounts may use ImmutableOwner, with TransferFeeAmount required for mints with TransferFeeConfig; other account extensions are rejected. Account rent is estimated for the required layout, including any existing lamport funding.

1. The taker reviews and signs the prepared transaction.
2. The maker signs the identical transaction message.
3. The service verifies both signatures and submits the fully signed transaction.
4. Reconciliation checks a successful finalized receipt whose serialized message matches the approved message.
5. Only then does the database reduce remaining quantity and record the completed fill and fees.

The signature endpoint rejects altered transaction messages, unrelated signers and a maker signature submitted before the taker’s. Conditional signature updates prevent a concurrent change from silently replacing the reviewed attempt. Transactions execute atomically: a failed instruction rolls back exchange transfers, although network fees can still be charged.

Expiry and uncertain submission

Order expiry controls whether a new fill can start. Transaction validity is a separate blockhash window. Closing the page, disconnecting a wallet or changing an off-chain listing cannot revoke valid signed bytes.

If submission is uncertain, the service preserves the attempt and may rebroadcast those same bytes while valid. Before releasing it as expired, reconciliation checks finalized block height, blockhash validity and available signature/receipt evidence. An RPC failure is not interpreted as proof of cancellation. Trade pages poll while open; the application does not promise continuous background reconciliation or instant maker notifications.

8. Trading fees and integer arithmetic

The buyer pays a nominal 0.50% trading fee in the quote asset, in addition to the seller’s agreed proceeds. Half of that fee goes to the market recipient and the remainder to Sidelot. The two shares are nominally 0.25% of trade value; indivisible units can make the split differ slightly.

Let q be the gross base-token quantity sent by the seller in integer units, d the token decimals, e the quote decimals, and p18 the positive unit price scaled by 10^18. Quote decimals are 9 for SOL and 6 for USDC.

Q = ceil(q × p18 × 10^e / 10^(d + 18))
F = ceil(Q × 50 / 10000)
H = floor(F / 2)
S = F - H
buyer_payment = Q + F

Q is seller proceeds, F total fee, H market-recipient share and S platform share. The implementation uses integer arithmetic, validates precision and bounds, and requires wallet-held quote amounts of at least 100 quote base units.

For 100.000001 USDC of proceeds, Q = 100000001 base units. The total fee rounds up to 500001 units, or 0.500001 USDC. The market receives 0.250000 USDC, Sidelot receives 0.250001 USDC, and the buyer pays 100.500002 USDC. This example illustrates rounding, not expected trade size or earnings.

Network transaction fees and account rent are separate. For wallet-held settlement, the taker pays them even when the taker is the seller. Funded activation, deposits and withdrawals have their own payer and account costs. Self-payments to a participant who also owns a fee wallet reduce their net cost without changing nominal accounting.

Fees transfer during successful settlement; the dashboard is not a separate claimable balance. Its displayed totals cover recent records, not guaranteed lifetime accounting. See Fees and Dashboard and fees.

Token transfer fees

Supported Token-2022 TransferFeeConfig mints charge a token fee independently of the 0.50% quote-currency trading fee above. For gross token amount q, the token fee is min(maximumFee, ceil(q × basisPoints / 10000)), in atomic base-token units; the buyer receives q − token_fee. A 1,000-token transfer at 1% delivers 990 tokens when the cap does not bind. The quote price remains per gross token. Fees and caps apply per transfer, so partial fills can have different aggregate token fees. Zero-net transfers are rejected.

Preparation reads the mint fee configuration and current epoch. Public previews include the current and any scheduled fee, plus the configuration authority. The prepared transaction uses TransferCheckedWithFee with an exact expected fee. The trade receipt shown for signing is decoded from that transaction, not recomputed from a later mint snapshot. A different fee at execution causes the atomic transaction to fail; network fees may still be charged. A configuration authority can schedule changes, and neither a listing nor its preview guarantees a later fee. Token accounts for these mints require TransferFeeAmount alongside any ImmutableOwner extension; missing ATA rent is estimated for the resulting 182-byte layout.

9. Optional funded escrow

The funded mode is a separate native Solana Rust program restricted to original SPL tokens. Token-2022 market support does not enable Token-2022 deposits or fills through this program. Its source defines market initialization, order creation, fill, maker cancel/reclaim and permissionless expiry. New public deposits remain disabled until an actual deployment is configured and enabled; a market must then be activated by its launcher.

Deposits and account authority

Each order has deterministic addresses derived from the deployed program, maker and seed. Market and order state accounts are owned by the escrow program. Token vault accounts are owned by the SPL Token Program, while the order PDA controls token transfers through program signing. There is no universal Sidelot deposit wallet.

Creation checks signers, mint ownership, decimals, supported quote, expiry and derived accounts, then deposits and records the order atomically. Pending funding in D1 is excluded from the open book until finalized funding is verified. A USDC base-token market cannot choose USDC as its quote.

Fills and refunds

A taker signs a fill without requiring another maker signature. The program verifies the recorded maker, market, fee recipients, mints, vault, open status and on-chain expiry. The instruction carries an expected already-filled quantity and maximum nominal buyer debit. A competing fill changes that cursor; stale instructions fail instead of silently executing changed terms.

An ask sends deposited tokens to the taker and collects their payment. A bid receives the taker’s tokens and pays them from deposited quote funds. Transfers and progress counters update together. Funded prices cannot be edited; cancel and replace to change them.

Maker cancellation returns only the balance remaining when it executes. A fill may land first. Expiry stops new fills but does not automatically send a refund. The program’s Expire instruction can be submitted by anyone after expiry, with proceeds still restricted to the maker. The current website exposes maker cancel/reclaim.

Reclaim returns unused funds and unsolicited surplus. Token-vault closure returns its rent, but market state and terminal order state remain allocated. The order is retained as a tombstone to prevent identity reuse. A filled token vault can require a later reclaim to close. Issuer freezes can block both settlement and refunds until the issuer permits transfers.

10. Conserving partial-fill funding

Funded orders represent price as original total quote value divided by original base quantity. Rounding each fragment independently could spend more than a bid deposited. The program instead calculates cumulative entitlements, then pays the difference from its stored counters.

For original quantity N, total quote value V and cumulative filled quantity x, all in integer asset units:

Q(x) = ceil(V × x / N)
F(x) = ceil(Q(x) × 50 / 10000)
H(x) = floor(F(x) / 2)
S(x) = F(x) - H(x)
fill_payment = entitlement(after) - entitlement(before)

A small arithmetic example uses N = 3 and V = 201 quote units. A funded bid deposits 203 units: 201 principal and two fee units.

The three fills pay fee deltas of one, zero and one unit. Charging a freshly rounded fee on each 67-unit fragment would incorrectly total three. Cumulative differences preserve the original two-unit budget. This is an arithmetic illustration, not a recommendation to trade dust.

The Rust implementation uses checked wide intermediates and bounded outputs. It rejects zero-quote fills and a partial fill that consumes all quote entitlement while leaving base tokens stranded. Finalized account reconciliation verifies quantities, terms and cumulative counters, and updates the off-chain mirror monotonically by observed slot. The contract reference contains the full arithmetic and account model.

11. Programs and address classification

Wallet-held settlement uses standard Solana programs; it does not require a custom Sidelot swap-program address. The custom escrow source does not hardcode a public deployment identity.

The canonical USDC mint, EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, is an asset identifier, not an escrow program. The configured platform fee wallet, DZW2Hho1VMJSGno1inJiKTKosibVmS6NHVfHX76TQruf, receives fees and is not a trading deposit vault. Market recipients and future escrow accounts have separate roles.

The deployment verifier checks the configured network and genesis, loader ownership, the canonical ProgramData address, and the program and ProgramData accounts from one finalized snapshot. It compares the deployed program bytes with the pinned build hash and length and permits only zero-filled reserved capacity. New deposits also require the approved upgrade authority and enabled configuration. Fills use the order’s original program with that authority policy. Cancellation and reconciliation retain the original program and approved bytecode checks while allowing an authority change, so changing the deposit setting or authority alone does not intentionally disable recovery.

These checks establish correspondence with an approved artifact at the observed chain state. They do not prove that its logic is correct or independently audited, and they cannot prevent an authorized upgrade after the check. Future releases must preserve approved historical artifacts for outstanding deposits; checking every old program only against a replacement build would obstruct recovery. Reconciliation separately checks stored account layouts and order terms.

The Rust reference source and ABI are public for review. Publishing them is not a deployment announcement. Programs and addresses explains the distinction.

12. Public API and AI-assisted listings

The public v1.1 API provides market and offer discovery, token compatibility checks, quotes, product status, wallet-authorized market registration, and wallet-held offer posting and cancellation. It requires no API key. It does not expose public order execution, escrow deposits or autonomous spending through the launch endpoints.

Prepare → review → sign → commit is the registration flow. POST /api/v1/markets/prepare accepts a launcher wallet and strict market object. It validates the mainnet connection, mint, fields and owned image IDs, then returns a five-minute challenge. The exact UTF-8 message includes the approved market JSON, its SHA-256 digest, site origin, network, owner, fee recipient, nonce and expiry.

The owner reviews these terms and signs that exact message. POST /api/v1/markets/commit accepts only the challenge ID and a base64-encoded 64-byte signature. The service verifies it against the stored message and owner, revalidates mint details and images, and atomically inserts the market while consuming the challenge. The challenge ID is also the market ID.

Valid retries of a completed launch return the same market while its challenge remains retained; they do not create another market. Clients should save the returned ID and retry uncertain commits with the same authorization rather than repeatedly asking for new signatures. Challenge cleanup makes this recovery window bounded, not permanent.

An agent can prepare a wallet-held buy or sell offer using /api/v1/offers/prepare. The owner reviews the exact mint, side, quote, gross quantity, fixed price, fee schedule preview, net-receipt example, expiry and fee recipients, then signs the returned message and commits through /api/v1/offers/commit. Decimal strings preserve precision. An offset converts a caller-supplied reference and basis-point adjustment into a fixed price; it does not create a floating-price order or certify the reference as current. The five-minute authorization deadline and the 1, 3, 7 or 30-day offer expiry are separate.

An offer is an unfunded listing. Posting it reserves no balance and moves no assets. Public offer reads report stored state without checking balances or reconciling the chain. Settlement still needs separate approvals from both traders. /api/v1/offers/cancel/prepare and /commit authorize cancellation only for an owned, open wallet-held offer with no active trade, at the reviewed revision. Editing, funded cancellation, deposits and trade execution are outside this public API.

Offer creation and cancellation use action-scoped signatures and atomic database guards. Exact successful commits can be retried without duplicating the action. The browser client snapshots reviewed terms and saves the signed request before sending. Cancellation has separate quotas so a creation-rate limit does not prevent eligible cancellations.

HTTP 429 includes Retry-After. A creation response explicitly identifies application access as public beta, with market creation password protected. An agent may draft metadata and coordinate calls; it should not ask for private keys, treat generated text as authorization or hide the fee recipient from the signer. The builder guide and OpenAPI specification define the actual integration contract.

13. Threat model and operational boundaries

Balances and counterparties. A wallet-held listing is not proof of reserved inventory. Balances can change after preparation, counterparties may decline to sign, and tokens can become frozen. Funded inventory removes the need for a new maker signature but does not create demand or remove program risk.

Races and replay. Conditional reservations, exact-message checks, single-use action challenges, signature verification and funded fill cursors address specific stale-state and replay paths. They do not establish unique human identities. Multiple wallets can be controlled by one person, and public registration is not project verification.

Application trust. Wallet-held terms and reservations depend on Sidelot’s service. Users must review actual transaction instructions and recipients. The application’s availability, database integrity and transaction presentation remain relevant even though it does not collect private keys. Message and transaction signatures should not be described as blanket protection against a compromised interface.

Deployment authority. The reference escrow source has no administrator-withdrawal instruction, market-fee change instruction or funded repricing instruction. An upgradeable deployment could have an authority capable of changing its behavior. Source/binary correspondence, deployment identity and upgrade policy must be established separately before public activation.

Data and chain access. DEX references can be incomplete, stale or distorted by thin liquidity. They inform comparison rather than enforce fair value. RPC and hosting outages can interrupt preparation or reconciliation; they are not evidence that signed transactions disappeared. Issuer freeze authority and public blockchain visibility also remain outside Sidelot’s control.

14. Release maturity, scope and network plans

This revision describes a public information site and public market and offer API alongside a public-beta trading interface. Funded escrow has an implementation and recorded local validation, with no activated public deposit service asserted here. Product status reports feature availability; it is not a continuous uptime monitor.

The October 4, 2026 validation reproduced the pinned binary and passed three Rust unit tests, 74 compiled-program checks, 37 deployment-verifier checks, and local API flows for both buy and sell orders in SOL and USDC. Additional API checks covered paused-deposit recovery and paginated historical orders. That evidence covers exercised behavior, not an independent audit, formal verification, a mainnet deployment or a successful real-funds end-to-end trade. Public funded launch requires further security review, verified deployment facts and operational validation.

Activation is a release sequence, not simply changing a flag: review the program; approve the deployment identity, payer and upgrade-authority policy; verify the deployed artifact against the intended build; validate finalized deposit, fill and recovery behavior; then enable the configured network. Each market launcher must still approve its own on-chain market activation before deposits open there. This paper authorizes none of those deployment or funding actions.

Robinhood Chain is the main network; its contract activation status is documented in the Robinhood guide. No verified active contract address is published in this release. The existing Solana beta remains available. Ethereum and BNB Chain remain planned support. Solana authorization and program rules do not establish equivalent behavior on those networks. No delivery date is promised by this paper.

Current scope excludes Token-2022 funded escrow, Token-2022 mint extensions other than MetadataPointer, TokenMetadata and TransferFeeConfig, cross-chain bridging, automatic order matching, floating-price orders, leverage, guaranteed fills and guaranteed savings. The market model does not require a reward token or promise holders an airdrop, yield or governance rights. Promotional launch offers are separate from settlement economics and governed by their own published terms.

15. Glossary and further reading

Continue with the platform documentation, wallet-held swaps, funded escrow, contract reference, API and agents, or troubleshooting. The Rust source and ABI support technical review; Product status should be consulted for availability changes. Questions can be directed to @SidelotOTC.

Planned deal capabilities

The following seven capabilities are coming soon. Each has its own release requirements, separate from the underlying network and exchange contracts. They are proposed designs, not enabled products, deployed contracts or API endpoints. They have no announced release date. Read the visual guide for a plain-language introduction and the coming-soon documentation for their intended operation.

Community Buyouts: Buy a big position together.

The proposed design holds the seller's tokens and buyer contributions under escrow rules. The success threshold, maximum accepted funding, allocation method and deadline must be fixed before contributions open. A successful finalization would establish payment and token claims; individual buyers may need separate claim transactions. This is different from an ordinary partial-fill order, where each purchase completes independently as buyers arrive.

A target is not guaranteed to fill. This buys a token position, not ownership or control of the project. A failed deal may require each contributor to claim a refund; it is not a promise of an instant automatic payment. Read the planned workflow.

One-Link Deals: Send the deal. Skip the back-and-forth.

The planned offer-focused page would resolve a stable offer identifier and retrieve its current terms and status. Opening a link must not create approval or bypass access, eligibility or signature checks. Expired, cancelled or filled offers should show their real state instead of presenting an executable trade. Existing market URLs, API offer records and trade-attempt links are separate capabilities; this dedicated deal experience is not available yet.

A link is an invitation to review, not acceptance of a trade. It does not guarantee liquidity, remove wallet approvals or bypass the current trading preview restriction. Read the planned workflow.

Commitment Deals: Choose when your tokens unlock.

The planned delivery mode would send purchased tokens into a vesting account instead of directly into a spendable wallet balance. A schedule may have a waiting period, a single unlock date, or gradual releases. The seller's payment and creation of the buyer's token claim must be tied to the same approved settlement. Exact schedule options, claim costs and cancellation rules will be documented before activation.

A discount is not yield or guaranteed profit. Locks apply to the purchased allocation, not every token the buyer owns. They do not prevent trading elsewhere with other holdings or selling after an unlock. Read the planned workflow.

Sidelot Rules: Make the terms clear upfront.

The planned first version uses reviewed, predefined settings for eligibility, timing, lot size and delivery. Agreed terms must be bound to the signed authorization and checked during settlement, with no silent edits after funds are committed. This is a proposed Sidelot deal-policy system, not a deployed Uniswap v4 hook or permission to run arbitrary user-written code over customer funds.

Rules apply to participating Sidelot deals. They do not change an existing coin globally, control trading on other exchanges, or bypass restrictions imposed by the token itself. Read the planned workflow.

Agent Deal Rooms: Let an agent find the other side.

The planned room adds quote discovery and negotiation on top of exact owner-approved terms. An agent would prepare a proposal, not gain spending authority just because a wallet connected. This is separate from today's public API, which can register markets and post or cancel wallet-held listings with message signatures. That API does not currently negotiate, fill orders or authorize settlement.

Agent assistance does not guarantee a match, the best price or a profitable trade. Wallet connection and listing approval are not approval to move funds. Read the planned workflow.

Sealed Offer Rounds: Make your offer before the reveal.

The proposed flow separates bidding from revealing or evaluating bids. Before release, each supported round type must specify its commitment method, reveal deadline, price and allocation rule, tie handling, no-reveal handling, funding requirements and refund path. The exact cryptographic design is not deployed or finalized. These materials do not describe a working anonymous auction or a live bid-submission endpoint.

Sealed bid terms do not automatically hide participants, deposits or on-chain settlement. There is no promise of fully private trading, guaranteed allocation or a particular clearing price. Read the planned workflow.

Shared Offers Across Markets: Find more offers for your coin.

The planned discovery view groups offers by exact mint, chain and compatible payment and settlement terms. Each order keeps its original market attribution, fee recipient, availability and rules. One offer must not be counted multiple times because it appears in several views. Combining multiple orders into an execution plan is separate work and is not promised by simply showing a combined list.

A shared list does not create liquidity or guarantee that all displayed offers can be filled. This feature does not mean bridging assets or trading across different blockchains. Read the planned workflow.

Activation and approval boundaries

A future feature that accepts deposits must have its own verified custody, settlement and recovery paths before activation. Tests and release review must cover conflicting actions, expired offers, failed funding, partial claims, rounding, account identity and token-transfer failures. Production documentation must identify its network, active contract or program, administrator and upgrade permissions, supported token addresses, exact fees and cancellation rules. A description in this paper is not evidence of such a deployment.

The application should distinguish a proposed deal, a signed listing, a funded commitment, a finalized exchange and an outstanding claim. An invitation link or agent proposal cannot replace a required signature. Claims and refunds can require separate transactions and network costs; they must not be described as automatically completed merely because a deadline passed.

Predefined deal rules apply to the participating Sidelot transaction. They do not modify existing tokens globally or control other exchanges. Shared discovery does not create new liquidity, and sealed bidding is not a blanket privacy guarantee. Final feature-specific settings and fee schedules will be published before launch. Product status is the current availability reference.