Status and roadmap

Implemented in the reference implementation

• Intent, Mandate, Decision (payload v4; versions 1 to 3 still verified), order state machine (including working, pending_replace and replaced) and evidence chain as specified here.
• Ed25519 signing over canonical JSON, key discovery by key_id, single-use decisions.
• custodial_fairx enforcement.
• The 23-rule authorization pipeline, buying-power reservations, RESIZE and PENDING_APPROVAL.
• Venue adapter contract, with capabilities declared per asset class. Hyperliquid perpetuals (testnet) and Alpaca US equities, listed options and crypto (paper) are exercised with real orders and fills. A simulator is used for development.
• MCP binding (including place, replace, exercise, cancel, book reads, quotes, instrument search and rule requests) with OAuth protected-resource metadata and JWT verification.

Defined but not implemented (planned)

• Enforcement modes client_hook, watcher and venue_verified.
• A separately signed ExecutionReport.
• A read-only watcher that reconciles a venue account and flags orders without a decision.
• A mandate compiler that pushes parts of a mandate into venue-native limits (API wallet scopes, sub-accounts, venue position or size limits).
• Mobile delivery of PENDING_APPROVAL for one-tap approve or deny.
• A standard flow for requesting and granting mandates.
• A formal REST binding document.
• An option-chain search (agents currently build OCC symbols themselves).
• Calendar and diagonal spreads, and an exercise reservation for in-the-money calls at expiry (the outcome is recorded when the broker posts it).

Not started

• SDKs.
• A conformance test suite that checks an implementation using only the protocol.
• Bindings other than MCP.
• A public specification repository and issue tracker.

Not verified yet

• OAuth token refresh through the MCP binding.
• The PENDING_APPROVAL path end to end through an OAuth-connected MCP client.