The adapter interface
Every venue implements the same small surface:placeOrder(...),cancelOrder(...),cancelAll(...)streamFills(),streamPositions(),streamFunding()getMarket(marketId)— tick size, lot size, fee schedule, max leverageenforceCaps(caps)— reject any order that would breach committed risk caps
What lives above the adapter
- The grid engine (ladder generation, refill logic, PnL tracking).
- The AI loop (param proposal, risk-adjusted scoring).
- The Mantle proof layer (commit / attest / recall).
- The Telegram UX.
What lives below the adapter
- Venue-specific REST / WebSocket / RPC code.
- Venue-specific signing, rate limits, and error handling.
- Venue-specific normalization (symbols, decimals, funding conventions).
Why this matters
- Velocity. Adding a venue is one adapter, not a fork of the agent.
- Comparability. The same risk-adjusted score is computed the same way across venues, so attested track records are apples-to-apples.
- Resilience. A venue going down doesn’t break the engine — it just disables that adapter.