Skip to content
Version v0.4 (draft)
ChangelogContributing

Markets

Markets

How A2M connects an agent to a venue. Finn authorizes; FairX executes through a venue adapter.

A market in A2M is a venue the protocol can authorize and execute against. The agent never talks to the venue or holds its keys.

  1. Finn (the authorizer) judges an intent against the agent’s mandate and, if it is allowed, signs a single-use decision.
  2. FairX (the executor) verifies that decision and sends exactly what was signed, once, through a venue adapter.
  3. The adapter translates A2M orders into the venue’s native API, then reports acknowledgements, fills and account state back so FairX can reconcile and Finn can update the reservation ledger.
flowchart TD
  Agent["Agent"] -->|"MCP tools"| Gateway["MCP gateway"]
  Gateway -->|"POST /v1/authorize"| Finn["Finn authorizer"]
  Finn -->|"signed decision"| Gateway
  Gateway -->|"POST /v1/orders"| FairX["FairX OMS"]
  FairX -->|"gRPC Submit"| Adapter["Venue adapter"]
  Adapter --> HL["Hyperliquid"]
  Adapter -.-> Other["Further markets"]

The gateway is a thin MCP translation of the engine’s HTTP APIs. Finn and FairX are the engine. The adapter is reached over gRPC. Hyperliquid and Alpaca are the markets connected today; further markets use the same path and the same adapter contract.

Each venue has its own adapter and its own page, written to the same template: what the market is, how to connect, how an order flows, how A2M fields map to the venue, what is supported, how failures are handled, and the current status.

Market Product Status
Hyperliquid Perpetual futures, USDC margin Testnet, verified with real orders and fills
Alpaca US stocks and ETFs, listed options, and crypto quoted in USD, USDT or USDC Paper, verified with real orders and fills

Further markets will be added using the same page template.

A new market gets a page under this section, with these headings:

  1. What it is. The venue, its product and account model, and anything unusual about how it meets A2M.
  2. How to connect. How the account is authorized and which adapter settings to configure, using placeholders rather than real credentials.
  3. How it works. The path of an order from the agent, through the gateway, Finn, FairX and the adapter, to the venue, and back again for reconciliation. Include a sequence diagram of that path.
  4. Mapping. How A2M fields correspond to venue fields, including identifiers, order types and times in force.
  5. Supported. Order types, times in force, reduce-only, precision, minimum size and any leverage handling.
  6. Reconciliation and failures. Timeouts, cancels, fill deduplication, expired decisions, and what happens when the venue is down.
  7. Status. What has been verified (for example on a test network) and what has not.

The adapter itself must implement the venue adapter contract.