Smart Contracts

Rave Trading settles tokenized-asset trades through on-chain contracts on multiple chains. The stable integration path is: call the proxy address returned in firm-quote transaction packets, and read token and allowance metadata from the live /v2/assets and /v2/limits endpoints — no manual address edits needed.

This page is a verification surface. Where an address can change (implementation contracts behind a proxy), confirm it against the live on-chain value using the explorer links below.

Chains and contract addresses

Rave's SettlementRouter is deployed on four chains, and quoting is live on all four. The proxy address is identical on BNB Smart Chain, Base, and Robinhood Chain, so the address alone does not identify the chain. Take execution.transaction.to and execution.transaction.chain_id together from the firm-quote packet and check both before signing.

Quote tokens and their decimals

A chain can advertise more than one quote token, and decimals is a property of the token contract on that chain, not of the ticker. USDC has 18 decimals on BNB Smart Chain and 6 on Ethereum and Base, so a decimals value carried across chains is wrong by a factor of 1e12. Never infer decimals from a symbol, and never reuse one chain's value on another.

That table is a verification aid. The advertised set is live, so read chains[].quote_tokens[] from /v2/assets and convert with the decimals it returns for the exact token address you are quoting.

Which symbols quote, on which chain, and on which side, is a live property. Read it from /v2/assets and /v2/markets/levels. Do not assume a symbol is quotable on every chain, or that both sides are open on a chain where one is. Resolve addresses from chains[].chain_id and chains[].token.address; V2 does not expose the older top-level bsc_address alias.

# Live asset catalog: token and quote-token addresses for every chain
curl -s "$RAVE_API/v2/assets" -H "Authorization: Bearer ***" \
  | jq '.[] | {symbol, chains: [.chains[] | {chain_id, token: .token.address, quote_tokens: [.quote_tokens[].address]}]}'

Narrow the same output to one chain by filtering on chain_id:

# One chain only; set CHAIN_ID to one of the chain IDs in the table above
curl -s "$RAVE_API/v2/assets" -H "Authorization: Bearer ***" \
  | jq --argjson chain "$CHAIN_ID" '.[] | {symbol, chain: [.chains[] | select(.chain_id == $chain) | {token: .token.address, quote_tokens: [.quote_tokens[].address]}]}'

Allowance targets

Before a firm quote can settle, the taker must approve token_in to the router/spender for that chain and side. Read the exact spender from /v2/limits rather than hard-coding it:

# Allowance target per symbol, chain, and side
curl -s "$RAVE_API/v2/limits" -H "Authorization: Bearer ***" \
  | jq '.assets[] | {symbol, chain_id, buy: .sides.buy.allowance_target, sell: .sides.sell.allowance_target}'

See the Integration Guide for the full approve-before-execute checklist.

Verification Details

The SettlementRouter is an ERC-1967 UUPS proxy. The proxy address is stable and is the only address integrators call. The implementation address behind the proxy changes with upgrades, so never pin it in an integration or documentation table. Live read required: read the current value from the EIP-1967 implementation slot (0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc) on the proxy, or use the block explorer's proxy "Read as Proxy" view; explorer links for every chain are in the table above. Integrators should always call the proxy; the implementation address is provided for verification and transparency only.

Upgrade history (implementation provenance)

2026-09-02 Base and Robinhood Chain first deployments (no prior implementation on either chain; the two implementations hold byte-identical runtime code):

• Base: implementation deploy tx 0x41bb6a27b266bbb65fa55737faddc0ff32158c424c9ecf6fff47a6dc9c7915a9; proxy creation tx 0x6e10fc075ed8e7a22fdb80ea390ac260db32faf4fa4ee9fcae4ba47ef2c053c1
• Robinhood Chain: implementation deploy tx 0xe626ebc100b83c29485cb0dd0b33f6894fb8b4119ac288253722b3ad5902591c; proxy creation tx 0x6ca52973f3989163899fcc0894b1bccbf520bc80fb85f18dfef49be8e501900f

2026-05-19 BSC storage-layout recovery upgrade (consumer-facing execute/executeV2 selectors unchanged):

• BSC: upgrade tx 0x0525ad7c7d4ad13e204303612982c5170f3deb190ba3a2f5802904106b1c1cee; implementation deploy tx 0x7a334e0dd59f4196404a7c9e4898a58c7a6020d54507f0ce731e1f03f0a6baba; ABI hash 6d5af487a1e51e01e4c099608b155c4b7f7610c96ff9a9dcdf57e72c9e585a8d; Sourcify matchId 29654590

2026-05-18 via-IR upgrades (empty upgradeToAndCall — ABI/selectors/storage layout unchanged):

• BSC: upgrade tx 0x15efb67c4653c1dfd011916ff2a73e3db68b9c76fa0bfd7a07a895ac47db11c1; implementation deploy tx 0x056e08c4eb6e6acb3eeba555c205d0d9074e5ee8d467c009a557902a3e002ff2
• Ethereum: upgrade tx 0x628873de04a5e68210c1c8d475513d5e8cfa1e65083a2f594e1226faee64cc56; implementation deploy tx 0xf6d7a2366cc71d81d756069697ad9f76fef8a9deb7bc47b4b1a593458b9b873e

The Ethereum implementation has since been upgraded again, so the 2026-05-18 transaction no longer names the live implementation. Always read the current implementation from the proxy on-chain before verifying source.

Compiler settings

New SettlementRouter implementations are compiled with Solidity's via-IR pipeline (solc 0.8.28, optimizer runs 1, EVM cancun, metadata-stripped with bytecode_hash = "none" and cbor_metadata = false). When verifying the implementation contract on a block explorer, include viaIR: true and optimizerRuns: 1 in the compiler settings — otherwise the verification will fail even though the source code is correct.

Roadmap / Upcoming Contracts

The contracts in this section are source-only and not yet deployed on-chain. Do not build production integrations against them until an explicit on-chain deployment announcement provides live, verified addresses. The stable integration path remains the proxy addresses above plus API-discovered token/allowance data.

The executeExternalRfq function (selector 0xe0aa8b21) is staged in SettlementRouter source for provider-neutral external RFQ execution. It accepts a signed ExternalRfqOrder with transaction-data hash verification, pulls and retains fees, dispatches order-target transaction data, and forwards output to the recipient. It is source-only — do not rely on the selector until it is deployed and verified.

Two periphery contracts are staged for external settlement providers:

These contracts will be documented with live addresses once deployed and verified on-chain.