Core concepts

The life of an order

1. Intent. The agent sends an intent with its own intent_id. Reusing the id with the same body is idempotent; reusing it with a different body is a conflict (A2M_IDEMPOTENCY).
2. Judgement. The authorizer finds the agent’s single live mandate and runs its rule pipeline in a fixed order, stopping at the first failure.
3. Decision. The authorizer returns a signed decision. On ACCEPT or RESIZE it has reserved the buying power the order needs. REJECT is also signed, so a refusal is attributable. PENDING_APPROVAL waits for a human.
4. Execution. The agent (or the binding on its behalf) hands the decision and signature to the executor. The executor verifies the signature, checks the enforcement mode, expiry and the venue’s declared capabilities, consumes the decision and sends the order.
5. Reports. Order state and fills flow back as an execution report. Fills settle the reservation; the unused remainder is released when the order ends.
6. Evidence. Each step appends a record to the evidence chain.

Dry run

/v1/check (MCP a2m_check) runs the same pipeline but reserves nothing and returns CHECK_PASS or a rejection. A CHECK_PASS is never executable.

Human approval

A mandate may set approval_above_notional. An order above it returns PENDING_APPROVAL with an approval_id. A human approves or denies; on approval the authorizer re-runs every rule before issuing an executable decision. Unanswered approvals expire (A2M_APPROVAL_EXPIRED).

Rule layers

Rules are grouped into layers so a refusal says who imposed the limit:

Layer	Examples
kya (know your agent)	agent registered and active, exactly one live mandate
user	instrument and venue allowlists, price collar, fat-finger caps, kill switch, direction, position limit, throttles
market	instrument listed, session open, reference price fresh, lot and tick, price band
broker	order type and time in force allowed, broker min and max notional
account	account open, buying power, budget, broker cash

The full order is in Decision and signing.

Enforcement

Each decision says who stands between it and the venue (enforcement). Only custodial_fairx, where the executor holds the credential and is the only path to the venue, is implemented. Other modes are defined but planned. See Security model.

Reference implementation

A reference implementation exists (authorizer and executor in Go, venue adapters in Python, gRPC between them) and runs against the Hyperliquid testnet. In it the authorizer is called Finn and the executor FairX; the enforcement value custodial_fairx comes from that name. It is not yet public.