Sidelot on Robinhood Chain

Network and contract status

Robinhood Chain is Sidelot’s main network. Create a market for an existing coin, help buyers and sellers agree on direct trades, and route a share of completed trading fees to your chosen wallet. Holders and teams can launch; creating a market does not create a coin.

Testnet deployment verified on October 15, 2026 (UTC). The registry and exchange are deployed on Robinhood Chain testnet, chain ID 46630. Runtime bytecode and configuration were checked, and a 19-transaction test completed market registration, funded sell and native-ETH buy partial fills, a signed wallet-held sell, cancellation while paused, unused-budget refunds and permissionless expiry recovery. The test ended with no remaining base tokens or native ETH in escrow. These are testnet results, not an independent security audit.

• Registry: 0x7881ba1c228c239897ec7B6973070c77E2Aa969D. Deployment receipt.
• Exchange: 0xD034ec5f231BDC6398Ce5DD494e1e1D3B65f9394. Deployment receipt.
• Test token: 0x3f70f0BCe50DA89267175f5Ac45D68Ad37FcDE46, used only for this testnet validation.

Mainnet deployment and activation remain pending. No Sidelot registry or exchange has been deployed on chain ID 4663. Mainnet deployment requires ETH for gas, followed by deployment verification and application activation. The testnet addresses above must not be treated as mainnet contracts. Open the Robinhood workspace or Product status for the configured network’s current availability. A connected wallet or a successful chain switch does not establish that settlement is available.

Solana remains a separate beta network. Sidelot is independent and is not operated or endorsed by Robinhood.

Choose the exact network

Robinhood Chain uses EVM accounts and ETH for network gas. Its token contracts and wallet approvals are different from Solana mints and programs. A token symbol is not an identifier: verify the network and full contract address together.

Testnet assets are for testing and have no promised monetary value. A testnet deployment does not activate mainnet trading. A chain switch does not bridge assets, and the Solana version of a coin is not automatically the same asset on Robinhood Chain.

Launch your market

The launch experience has four decisions: who the market is for, which existing token it trades, what the market looks like, and where its fee share goes. Robinhood Chain uses an EVM token contract address and EVM recipient address. Do not paste a Solana mint or wallet into it.

Review the token, market owner, fee wallet, network and contract before approving. On-chain registration requires a wallet transaction and ETH for gas. A signed request, submitted transaction and confirmed market are different states; share the market after the interface verifies registration.

1. 01Choose community or solo, and identify yourself as a holder or team.
2. 02Enter the existing Robinhood Chain token contract and review its compatibility.
3. 03Name the market, add its details, and choose the fee-recipient wallet.
4. 04Review the exact network and registration transaction, approve it, and wait for confirmation.

Separate registry and exchange contracts

The exchange architecture contains SidelotMarketRegistry and SidelotExchange. The registry records the token, creator, fee recipient and metadata reference. The exchange enforces token delivery, payment, fees and order state. These contracts are non-upgradeable; market identity and the configured platform fee recipient are fixed. No deployed address has been verified for public use in this release.

The exchange has a guardian using two-step ownership transfer. The guardian can pause new funding and fills; it does not have an instruction to seize deposited funds. Maker cancellation and recovery remain available while paused. A pause does not complete refunds or remove token-specific transfer restrictions. Verified source, bytecode, constructor values and the actual guardian address must be published before activation.

A market listing is not a pooled deposit. Wallet-held offers leave assets in the maker’s wallet until execution. Funded orders deliberately deposit assets into the exchange under the order’s terms. The application must distinguish these modes before asking for approval.

Community Buyouts, Commitment Deals and the other planned capabilities remain separate work. Deploying a basic exchange does not activate those features.

Connection, token approval, signed offer and trade

Connecting exposes your public EVM address and chosen network. It does not transfer assets. Token approval allows the exchange contract to transfer an approved ERC-20 amount; check the exact spender address and allowance. The initial exchange uses ERC-20 approvals, not permit signatures. Signing an offer authorizes its exact terms under EIP-712 typed data. Submitting a trade sends a transaction that must succeed before settlement is recorded.

The EIP-712 domain uses SidelotExchange, version 1, and binds the chain and exchange address. The order binds the maker, market, quote asset, quantities, expiry and nonce. The contract validates maker signatures, including compatible ERC-1271 contract wallets, and tracks filled amounts and cancellations on chain. A signature for one chain or exchange must not be accepted on another. Contract-wallet signature support does not guarantee that every wallet is supported by the browser interface.

Native ETH cannot be pulled from an offline wallet through a token allowance. Wallet-held sell offers can collect ETH from the buyer submitting the fill. A wallet-held buy offer instead needs an ERC-20 quote asset, such as an explicitly supported wrapped-ETH token, plus the maker’s allowance and balance. A funded buy deposits its ETH or ERC-20 quote amount and fee budget in advance. Token and quote assets must differ.

The exchange supports ERC-20 quotes at the contract level, but the interface may support a narrower list. A contract accepting a quote address is not a token endorsement. Do not assume a wrapped-ETH or stablecoin address from another chain is valid on Robinhood Chain.

Start with standard ERC-20 tokens

The initial Robinhood implementation targets standard ERC-20 transfers, with native ETH or compatible ERC-20 quote assets. It checks actual token balance changes so an unexpected deduction cannot silently reduce the agreed delivery. Transfer-tax, rebasing and other nonstandard transfer behavior are outside the initial supported scope. An ERC-20 name or symbol does not prove compatible behavior.

Solana Token-2022 tax support does not carry across to an EVM token. A token rejected on Robinhood may require additional contract support and separate review. Sidelot’s trading fee is separate from any issuer-defined token fee.

A successful compatibility check is a point-in-time check, not a promise that a token cannot pause, blacklist, upgrade or change behavior later. Those powers can affect fills and refunds.

Exact balance checks still depend on the token contract reporting balances honestly. A malicious or upgradeable token can present additional risks. If a token changes to taxed, paused or restricted behavior after funding, it can obstruct both trading and withdrawal until valid transfers become possible.

Trading fees and ETH gas

The contract trading-fee model is 0.50% paid by the buyer, with half of that fee routed to the market recipient and half to Sidelot. The nominal shares are 0.25% each; integer rounding applies. Only successful completed trades generate the trading fee. Registering a market or posting an unfilled offer does not generate earnings.

ETH gas pays for transactions such as registration, token approval, settlement, funding and cancellation. Gas is separate from Sidelot’s trading fee and may be spent by a reverted transaction. Review the supported settlement path and transaction amounts in the interface before signing.

For illustration, a trade with 1 ETH seller proceeds and a 0.50% fee requires 1.005 ETH from the buyer before gas, routing 0.0025 ETH to the market recipient and 0.0025 ETH to Sidelot. This is an arithmetic example, not an active offer or earnings forecast.

Cancelling an offer or recovering a deposit

The maker can cancel a valid signed order or a funded order. Closing a tab or deleting an off-chain listing does not revoke an on-chain-valid signature. The cancellation transaction must succeed, and a valid fill may execute first. Partial fills use cumulative accounting so the remaining balance and fee budget match the unfilled portion.

Cancelling a funded sell returns the remaining base tokens. Cancelling a funded buy returns unused quote principal and its unused buyer-fee budget in one atomic transaction. The maker can choose a refund destination and can cancel while the exchange is paused. Anyone may submit the expiry operation after the deadline, but that operation refunds only the maker. Expiry itself does not automatically send funds.

Native ETH recipients must accept payment; a rejection reverts the entire transaction. If a maker’s cancellation refund destination rejects ETH, the maker can retry with another destination. A fee recipient that rejects ETH can prevent ETH settlement. Token freezes, taxes, blacklists or changed token behavior can also prevent fills and refunds.

A successful receipt, rather than a submitted hash or expired listing, establishes completion. The interface must continue identifying the exact exchange and network that hold each outstanding deposit.

Deployment verification

1. Complete and review the registry, exchange, wallet flow and exact-amount accounting.
2. Exercise registration, buy/sell execution, partial fills, fee routing, expiry and cancellation against isolated tests and the intended test network.
3. Confirm the deployment payer, platform fee recipient, chain and constructor configuration.
4. Deploy and verify the actual contract addresses and bytecode on the chosen network.
5. Check real wallet flows and successful, reverted and recovery receipts before enabling deposits and trading.
6. Publish the verified addresses, token policy, fee configuration and known limits.

Local tests establish only the behavior exercised by those tests. They are not an independent audit, a mainnet deployment or proof of live liquidity. An interface should never call a transaction completed solely because a wallet returned a hash.

Network references and next steps

Use the official Robinhood Chain documentation for current network setup and the mainnet explorer for chain evidence. Verify any Sidelot deployment against the addresses published in the Robinhood contracts page, not a token’s name or an unsolicited message.

Read the whitepaper for the architecture, fees for cost explanations and Solana beta launch guide for the existing network’s workflow.