Skip to main content

Venues

A venue is anything an agent trades on. OAW models each as a declarative capability contract + one adapter. Seven reference adapters ship today across EVM and non-EVM.

VenueChainClassAuth / signingACP-nativeMaturity
PolymarketPolygonpredictiondeposit wallet · EIP-1271 · CLOBreference
HyperliquidArbitrumperp / spot / HIP-3·4API/agent wallet · approveAgentreference
Pump.funSolanatoken (non-EVM)managed Solana walletreference
BankrBasetokenBase accountreference
VirtualsBaseACP / tokenACP sidecar (Mode B)reference
DegenClawArbitrumperp / spotACP sidecar (Mode B)reference
Trade.xyzArbitrumperp / spotroute-proofreference
Binance · Kalshiregistry only

Venue classes

  • Prediction (Polymarket) — EIP-1271 deposit wallet + CLOB credentials, settles on Polygon via an any-chain deposit bridge.
  • Perps / spot (Hyperliquid, Trade.xyz) — an approved API/agent wallet on Arbitrum; Hyperliquid covers HIP-3/4 assets too.
  • Tokens (Pump.fun on Solana, Bankr on Base) — managed wallet / native account.
  • ACP-native (Virtuals, DegenClaw) — require a linked Virtuals identity + signer and execute through the ACP sidecar under a verified Mode B authority.

Adding a venue

It is data + one adapter — no core changes:

  1. Add a VenueCapabilityContract to the registry (keep bindingSupported: false until the adapter can service it).
  2. Implement a VenueAdapter (setup / readiness / fundingTarget / executeOrPlan) using the shared gatedExecute helper.
  3. If it settles on a new chain, add it to the funding chain map.
Reference, not live

Every venue above is a reference adapter — it proves the bind/fund/execute flow but makes no live venue API call. Each contract's integrationNotes lists exactly what to wire for production. See Capability status.