# M2M and x402 Machine-to-machine (M2M) commerce is the part of Brain where one agent pays another agent. Directly, on-chain, under the same policy, gate, and audit constraints as any other Brain payment. RFC 0001. {% hint style="warning" %} M2M settlement is **shadow-first**. The two new rails (`x402_base` and `escrow_base`) are **unregistered at boot and fail closed** until promoted; the underlying smart contracts (`BrainEscrow`, `BrainReputationRegistry`) are **unaudited testnet** reference implementations. No money moves through them until they're audit-batched and the rails are explicitly promoted in a tenant's configuration. {% endhint %} ### What M2M Adds. Nothing About the Gate Changes Brain didn't grow a parallel money path for agents. It grew **two new `action_type`s** that flow through the *same* `PaymentIntent → Policy → §6 gate → Audit` pipeline as everything else: | `action_type` | Rail | Settlement | | ---------------- | ------------- | ---------------------------------------------------------------------------------- | | `x402_settle` | `x402_base` | USDC on Base via the [x402](https://www.x402.org/) HTTP-native settlement standard | | `escrow_release` | `escrow_base` | Release (full / partial / dispute-split) of a `BrainEscrow` lock | The §6 pre-execution gate still runs. The audit chain still anchors. Policy still decides. M2M is **not** an opt-out of any of that. ### Two Settlement Patterns | Pattern | When | | --------------- | --------------------------------------------------------------------------------------- | | **x402** | Atomic, single-shot machine settlement. "I've finished the work, pay me now in USDC." | | **BrainEscrow** | Multi-step engagements. Fund up-front, release on milestones, dispute splits if needed. | x402 is the right primitive when the payee is verifiable in real time (a service responds, you settle). Escrow is right when the work is bounded in advance and there's a possibility of dispute or staged release. ### Agent Counterparties The payee in an M2M payment is *another agent*, not a vendor. Brain models this as an **agent counterparty**. A counterparty whose `type` is `agent` (or `wallet` with an attestation linking it to a registered agent in [`BrainMCPAgentRegistry`](/smart-contracts/brainmcpagentregistry.md)). The §6 gate's check 5.5 verifies that an agent payee is registered + active before any M2M settlement runs. ### The 5 Dormant §6 Checks for M2M Five gate checks were added at non-canonical positions specifically for M2M. They are **dormant-until-wired**: each adds a row only when the `PaymentIntent` carries the relevant settlement/escrow context **and** its on-chain loader is configured. For non-settlement payments (every ACH, wire, card\_payment) the canonical 13-numbered + 4-hardening path is unchanged. | Check | What It Enforces | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **On-chain-settlement permitted** (3.5) | The payment class is allowed to settle on-chain for this tenant (else it must route off-chain) | | **Agent-counterparty attested** (5.5) | When the payee is an agent, it is registered + active in `BrainMCPAgentRegistry` | | **x402 payment-context valid** (6.5) | The x402 `paymentRequirements` (amount, asset = USDC, network = Base, recipient) match the intent | | **Escrow-state bound** (6.6) | For an escrow release, the on-chain `BrainEscrow` lock matches: still `Locked`, enough **remaining** to cover this release, same payee, same `jobTermsHash` | | **Micropayment cap within window** (8.5) | Per-agent rolling-window spend stays within the policy envelope (mirrors the on-chain session-key window cap) | See [The Pre-Execution Gate](/protocol/the-pre-execution-gate.md) for the canonical 13 + 4 plus how the M2M extensions snap in. ### Reputation as a Tightener, Never a Gate Agent reputation lives in a separate, ERC-8004-style contract. [`BrainReputationRegistry`](/smart-contracts/brainreputationregistry.md) (RFC 0001, **UNAUDITED testnet**). Policy can read the per-agent reputation pointer and use it as a **tighten-only threshold input**. For example, "only auto-approve M2M settlements under $X to agents above reputation Y." **Reputation is never a money gate and never a §6 precondition.** A high score doesn't unlock anything beyond what Policy already allows; a low score can only tighten an existing rule. This is the same principle that keeps LLM judgment out of the §6 gate: signal that can move is allowed in; signal that can fail closed in dangerous ways is kept out. ### What Ships Today vs Later | Capability | Status | | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | | `x402_settle` / `escrow_release` action types on `POST /payment-intents` | Live in the spec; rails fail closed until promoted | | The 5 M2M §6 gate checks (3.5, 5.5, 6.5, 6.6, 8.5) | Live but **dormant**. Each becomes active only when its on-chain loader is wired | | `BrainEscrow` (custodial; partial release; dispute splits) | **UNAUDITED reference implementation** on testnet | | `BrainReputationRegistry` (ERC-8004-style pointer; RFC 0001) | **UNAUDITED testnet** | | Agent-counterparty schema, on-chain settlement reconciliation matcher | Live | | Mainnet promotion of the new contracts | **Requires external audit first**. Non-negotiable | ### Why M2M Belongs Inside the Same Gate The temptation in M2M settlement is to skip the gate "because it's machine-to-machine and fast." Brain rejects that: the gate is the **only** path to financial execution. An agent paying another agent is no different from a treasury system paying a vendor. The same evidence requirements, the same balance check, the same audit-event chain. The §6 design extends; it never shortcuts. This is what makes M2M commerce on Brain *auditable* in the same shape as everything else: every settlement produces a [Proof](/api-reference/proof-api.md) you can hand to a counterparty, an auditor, or a regulator. ### What's Next
💸 Payment IntentsThe Ledger entity x402_settle and escrow_release flow through./pages/frJ0ygywHJq5WCmjwuXH
🚪 The Pre-Execution GateThe canonical 13 + 4, plus the M2M extensions./pages/GcCCOqv3BXHFtEpuypqD
📜 Escrow and x402The on-chain contracts./pages/pdclcSITK44863badHKU
📜 BrainReputationRegistryThe reputation pointer contract./pages/0TL0aQXn4l3eiEqu51uS
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.brain.fi/protocol/m2m-and-x402.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.