Abstract

Model Context Protocol (MCP) today standardises how an agent reads from and writes to a tool. What it does not standardise is how an agent commits to a purchase on behalf of a user in a way that a regulator, a merchant and an insurer all find acceptable. This RFC proposes four verbs — nexus.intent, nexus.commit, nexus.settle, nexus.receipt — that extend MCP cleanly into the transactional domain.

1. Motivation

A well-meaning agent told to “book the cheapest flight tomorrow morning” today has to either open a browser automation loop or call a bespoke API for every supplier. Neither is auditable, and neither gives the user a single place to revoke consent. We need a surface where any marketplace can accept agent-initiated transactions without building agent plumbing from scratch.

2. Primitives

2.1 Intent

An IntentEnvelope is a signed, scoped request to commit to a transaction within named bounds. It carries the agent ID, the user consent token, the budget cap, the time window, the success criteria and a nonce. It is not a commitment; it is a negotiable offer.

2.2 Commit

A supplier accepts an intent by returning a CommitQuote that binds price, timing and cancellation terms for a named TTL. Once the agent counter-signs within the TTL, the commit is binding.

2.3 Settle

Settlement is performed through a pluggable payment rail (Stripe, Idram, M-Pesa, UPI, PIX, stablecoins, bank transfer). Funds are held in escrow until the success criteria verify.

2.4 Receipt

A ReceiptEnvelope is emitted at settlement. It is content-addressed and signed by all three parties — user, agent, supplier — and carries the hash of the original intent. It is the audit trail.

3. Example exchange

// Agent → Supplier: intent
POST /nexus/intent
{
  "intent_id": "01HW...",
  "action": "book_appointment",
  "params": { "service": "gp_consultation", "window": "2026-05-03T09:00..11:00Z" },
  "budget": { "max": 4500, "currency": "GBP" },
  "consent_token": "ct_...",
  "agent_id": "did:gera:agent:abc",
  "nonce": "...",
  "signature": "..."
}

// Supplier → Agent: commit quote
{
  "intent_id": "01HW...",
  "quote_id": "qt_...",
  "price": 3900,
  "currency": "GBP",
  "ttl_seconds": 60,
  "cancellation_policy": "https://.../cancel",
  "signature": "..."
}

// Agent → Supplier: counter-signed commit
{ "quote_id": "qt_...", "user_countersig": "..." }

// Supplier → Agent: settle → receipt
{ "receipt_id": "rc_...", "status": "confirmed", "hash_of_intent": "..." }

4. Open questions

How should partial-success settle when a multi-leg intent fails mid-way?
Should receipts be stored on-chain by default, or content-addressed off-chain?
Does the consent token include a budget window, or is budget a separate envelope?

5. Relationship to existing protocols

This RFC sits alongside MCP, not on top of it. A transactional MCP client speaks normal MCP for reads and these four verbs for writes that cost money. It is orthogonal to Google’s A2A and complements Anthropic’s agent-skills packaging work.

Call for comments

This draft is open for public review. File comments and objections on the research page or join the integrator waitlist. See also the deep dive on consent, escrow and receipts and the MCP vs A2A comparison.