aura-labs.ai

AURA Protocol Specification — Financial Protocol

Module: Financial Protocol (Sections 10–11) Parent: AURA Protocol Specification v2.2 Version: 2.2 Date: April 14, 2026 Covers: Transaction Commitment, Clearinghouse Settlement, Dispute Resolution, Market Profiles

10. Transaction Commitment Protocol

MVP Implementation: Consent is managed manually by the principal (user) at transaction commitment time. The Scout collects explicit consent from the user before including consent flags in the commit request.

Design Principle: The user MUST make conscious decisions about data sharing. Scouts SHOULD present consent options clearly and MUST NOT pre-select options that share more data than necessary for transaction completion.

Future Extension: Subsequent protocol versions will support automated consent based on user-defined boundary conditions (e.g., “always share email for order updates with merchants above reputation 80”).

10.2 Committing to an Offer

When Scout decides to purchase:

POST /v1/sessions/{session_id}/commit

Request:

{
  "offer_id": "ofr_01HABC...",
  "quantity": 1,
  "shipping_preference": "standard",
  "buyer_identity": {
    "name": "Jane Doe",
    "email": "jane.doe@example.com",
    "phone": "+1-555-123-4567"
  },
  "shipping_address": {
    "line1": "123 Main Street",
    "line2": "Apt 4B",
    "city": "San Francisco",
    "state": "CA",
    "postal_code": "94102",
    "country": "US"
  },
  "payment_method": {
    "type": "x402",
    "x402_payment": {
      "facilitator": "stripe",
      "payment_token": "pm_tok_...",
      "currency": "USD"
    }
  },
  "consent": {
    "share_identity_with_merchant": true,
    "share_email_for_order_updates": true,
    "share_phone_for_delivery": true,
    "marketing_opt_in": false,
    "consent_timestamp": "2026-01-14T10:34:50Z",
    "consent_method": "explicit_user_action"
  },
  "payment_terms_acceptance": {
    "accepted_dispute_window_days": 30,
    "accepted_return_policy_days": 14,
    "accepted_payment_timing": "on_fulfillment"
  },
  "settlement_method": "stablecoin_usdc",
  "settlement_wallet": {
    "network": "ethereum",
    "address": "0x742d35Cc6634C0532925a3b844Bc9e7595f2bD..."
  }
}

Consent Fields:

Field Required Description
share_identity_with_merchant Yes Allow revealing buyer name to merchant
share_email_for_order_updates Yes Allow merchant to send order status emails
share_phone_for_delivery No Allow sharing phone for delivery coordination
marketing_opt_in Yes Allow merchant to send marketing communications
consent_timestamp Yes When user provided consent (ISO 8601)
consent_method Yes How consent was obtained (explicit_user_action, pre_configured_policy)
sub_intent_id No Reserved (Section 5.4.5). Sub-intent this commit settles. Null for simple sessions.

This is the ONLY point where Scout identity is revealed.

10.2.1 Pre-Commitment Validation (Phase 7)

Before accepting the commit request, Core validates the transaction against clearinghouse requirements. Validation runs in order — first failure short-circuits:

  1. Offer negotiation status. If the offer has terms_negotiable: true, it must be in accepted negotiation status (Section 4.4.2). Offers with terms_negotiable: false are accepted in proposed status (take-it-or-leave-it terms).
  2. Protocol minimums. Payment terms must meet protocol floors: dispute_window_days >= 7, return_policy_days declared. Core rejects below-floor terms.
  3. Business rules gate. Beacon’s business rules (CLEARINGHOUSE.md Section 3.1) are evaluated: min_trust_level, min_consent_tier, blocked_jurisdictions, min_transaction_count, max_transaction_amount, required_payment_methods. Any failure returns 403 BUSINESS_RULE_VIOLATION with the specific rule that failed.
  4. Consent elevation. Per DEC-040: Scout’s consent tier (from L5 or authority attestation) must meet or exceed the Beacon’s consent_requirements.minimum_tier. Failure returns 403 CONSENT_ELEVATION_REQUIRED.
  5. Settlement method compatibility. Scout’s settlement_method must match one of the offer’s payment_terms.accepted_methods. Failure returns 403 SETTLEMENT_METHOD_UNSUPPORTED.
  6. Payment terms acceptance. If payment_terms_acceptance is provided, the accepted terms must match or exceed the offer’s declared terms. Scout cannot accept a shorter dispute window than the offer declares.

If all validations pass, Core creates the transaction and initiates the clearing lifecycle (Section 10.7).

Response (201 Created):

{
  "transaction_id": "txn_01HXYZ...",
  "session_id": "ses_01HXYZ...",
  "offer_id": "ofr_01HABC...",
  "status": "committed",
  "created_at": "2026-01-14T10:35:00Z",
  "amounts": {
    "subtotal_usd": 349.99,
    "shipping_usd": 0.00,
    "tax_usd": 31.50,
    "total_usd": 381.49
  },
  "clearinghouse": {
    "clearing_id": "clr_01HXYZ...",
    "clearing_status": "risk_assessed",
    "risk_score": 0.0850,
    "beacon_risk_score": 0.0400,
    "scout_risk_score": 0.1200,
    "reserve_margin_pct": 0.0250,
    "reserve_margin_amount_usd": 9.54,
    "dispute_term_days": 30,
    "settlement_method": "stablecoin_usdc",
    "estimated_settlement_time": "2026-01-14T10:35:30Z"
  },
  "agreed_payment_terms": {
    "dispute_window_days": 30,
    "return_policy_days": 14,
    "payment_timing": "on_fulfillment",
    "settlement_method": "stablecoin_usdc"
  },
  "next_steps": {
    "action": "await_settlement",
    "expected_by": "2026-01-14T10:36:00Z"
  },
  "status_url": "/v1/transactions/txn_01HXYZ..."
}

Pre-Phase 7 compatibility: When the clearinghouse is not active, the clearinghouse object is omitted from the response. The status field returns pending (existing behavior) instead of committed. The agreed_payment_terms object is omitted. Existing integrators are unaffected.

10.3 Transaction Flow Sequence

Scout                    AURA Core                   Beacon
  |                          |                          |
  |-- POST /commit --------->|                          |
  |                          |-- Verify offer valid --->|
  |                          |<-- Offer confirmed ------|
  |                          |                          |
  |                          |-- Reveal buyer identity->|
  |                          |-- Payment authorization->|
  |                          |<-- Authorization OK -----|
  |                          |                          |
  |                          |-- Create order --------->|
  |                          |<-- Order confirmation ---|
  |                          |                          |
  |<-- Transaction created --|                          |
  |                          |                          |

10.4 Transaction Status

Scout polls for transaction status:

GET /v1/transactions/{transaction_id}

Response (200 OK):

{
  "transaction_id": "txn_01HXYZ...",
  "status": "confirmed",
  "status_history": [
    {"status": "pending", "timestamp": "2026-01-14T10:35:00Z"},
    {"status": "payment_authorized", "timestamp": "2026-01-14T10:35:15Z"},
    {"status": "confirmed", "timestamp": "2026-01-14T10:35:30Z"}
  ],
  "order": {
    "merchant_order_id": "ORD-ACME-12345",
    "merchant_name": "Acme Electronics",
    "items": [
      {
        "product_name": "Sony WH-1000XM5",
        "quantity": 1,
        "unit_price_usd": 349.99
      }
    ],
    "shipping": {
      "method": "standard",
      "estimated_delivery": "2026-01-17",
      "tracking_available": false
    }
  },
  "amounts": {
    "subtotal_usd": 349.99,
    "shipping_usd": 0.00,
    "tax_usd": 31.50,
    "total_usd": 381.49
  },
  "payment": {
    "status": "captured",
    "method": "card",
    "last_four": "4242"
  }
}

10.5 Transaction Cancellation

Scout may cancel before fulfillment:

DELETE /v1/transactions/{transaction_id}

Request:

{
  "reason": "changed_mind",
  "comments": "Found a better deal elsewhere"
}

Response (200 OK):

{
  "transaction_id": "txn_01HXYZ...",
  "status": "cancelled",
  "refund": {
    "status": "processing",
    "amount_usd": 381.49,
    "expected_by": "2026-01-17"
  }
}

10.6 Payment Capabilities Exchange

Scouts and Beacons declare their payment capabilities during registration. AURA facilitates capability matching to determine the optimal payment mechanism for each transaction.

Design Principle: Payment integrations will be added as needed. The protocol defines a capability exchange mechanism allowing agents to state their payment capabilities and agree upon the best mechanism. x402 is explicitly supported in MVP.

10.6.1 Scout Payment Capabilities

Scouts declare payment capabilities during registration or via update:

PUT /v1/agents/scouts/{scout_id}/payment-capabilities

Request:

{
  "payment_capabilities": {
    "supported_methods": [
      {
        "type": "x402",
        "facilitators": ["stripe", "square"],
        "currencies": ["USD", "EUR", "GBP"]
      },
      {
        "type": "card",
        "networks": ["visa", "mastercard", "amex"],
        "tokenization_provider": "stripe"
      },
      {
        "type": "bank_transfer",
        "regions": ["US"],
        "networks": ["ach"]
      },
      {
        "type": "crypto",
        "currencies": ["USDC", "USDT"],
        "networks": ["ethereum", "polygon"]
      }
    ],
    "preferred_method": "x402",
    "default_currency": "USD"
  }
}

10.6.2 Beacon Payment Capabilities

Beacons declare accepted payment methods:

PUT /v1/agents/beacons/{beacon_id}/payment-capabilities

Request:

{
  "payment_capabilities": {
    "accepted_methods": [
      {
        "type": "x402",
        "facilitators": ["stripe"],
        "currencies": ["USD", "EUR"]
      },
      {
        "type": "card",
        "networks": ["visa", "mastercard", "amex", "discover"],
        "processor": "stripe"
      }
    ],
    "preferred_method": "x402",
    "settlement_currency": "USD",
    "payout_schedule": "daily"
  }
}

10.6.3 Payment Method Negotiation

When Scout commits to an offer, AURA determines the optimal payment method:

  1. Intersection: Find methods supported by both Scout and Beacon
  2. Preference: Prioritize mutually preferred methods
  3. Cost optimization: Consider transaction fees where disclosed
  4. Fallback: Use most widely supported method if preferences don’t align

The selected method is included in the transaction record:

{
  "payment": {
    "negotiated_method": "x402",
    "facilitator": "stripe",
    "currency": "USD",
    "scout_preference_match": true,
    "beacon_preference_match": true
  }
}

10.6.4 x402 Integration

AURA explicitly supports the x402 HTTP payment protocol for seamless agent-native payments.

x402 Payment Flow:

  1. Scout includes x402_payment in commit request
  2. AURA proxies payment request to x402 facilitator
  3. Facilitator processes payment and returns confirmation
  4. AURA includes payment confirmation in transaction response

x402 Payment Object:

{
  "payment_method": {
    "type": "x402",
    "x402_payment": {
      "facilitator": "stripe",
      "payment_token": "pm_tok_...",
      "currency": "USD",
      "amount": 381.49,
      "idempotency_key": "idem_txn_01HXYZ..."
    }
  }
}

Future Payment Extensions: Additional payment methods (crypto stablecoins, BNPL, invoicing) will be added to the protocol as market demand and Beacon adoption warrant.

10.7 Clearinghouse Settlement (Phase 7)

Upon successful commit (201 Created), Core initiates the clearing lifecycle. The transaction progresses through the states defined in Section 4.5.1:

10.7.1 Risk Assessment

Immediately after commit, the clearinghouse computes bilateral risk scores:

  1. Beacon risk score — From Beacon reputation vector (fulfillment reliability, offer accuracy, dispute history), verification level, time-in-network, and category risk profile.
  2. Scout risk score — From Scout-principal verification level, consent tier (L5), transaction history, payment method reliability, authority attestation quality.
  3. Transaction risk score — From amount, payment method, product category, cross-border indicator.
  4. Composite risk score — Weighted aggregate (0.0–1.0). Produces the risk margin percentage and reserve amount.

All inputs are snapshotted to clearing_transactions.risk_inputs (JSONB) at assessment time for forensic reconstruction (CLEARINGHOUSE.md Section 8).

Transaction transitions: committed → risk_assessed (T18).

10.7.2 Authorization

After risk assessment, Core pre-authorizes the payment:

Beacon business rules are validated. Beacon receives the Scout risk score (without identity) and may auto-decline if the score exceeds its configured threshold.

Transaction transitions: risk_assessed → authorized (T19).

10.7.3 Settlement

The Settlement Orchestrator produces a signed settlement instruction — a cryptographically bound, idempotent directive to the configured rail adapter. The instruction is signed by Core’s Ed25519 settlement key and linked to the L6 commitment hash from the intent chain, creating a verifiable chain from human intent through to fund movement. See SETTLEMENT_RAILS.md Section 2 for the full instruction contract.

Settlement instruction (submitted to rail):

{
  "instruction_id": "stl_01HXYZ...",
  "idempotency_key": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "instruction_type": "collect",
  "clearing_transaction_id": "clr_01HXYZ...",
  "transaction_id": "txn_01HXYZ...",
  "amount": { "value": "381.49", "currency": "USD" },
  "source": {
    "principal_id": "prn_01HXYZ...",
    "settlement_wallet": "sw_01HXYZ...",
    "rail_account_reference": "acct_buyer_ref_abc123"
  },
  "destination": {
    "principal_id": "prn_01HABC...",
    "settlement_wallet": "sw_01HABC...",
    "rail_account_reference": "acct_seller_ref_def456"
  },
  "terms": {
    "payment_method": "rtp",
    "timing": "on_commit",
    "dispute_window_days": 30,
    "risk_margin_amount": "9.54",
    "risk_margin_currency": "USD"
  },
  "authorization": {
    "clearing_status": "authorized",
    "risk_score": 0.12,
    "business_rules_passed": true,
    "consent_tier": "explicit",
    "authorized_at": "2026-04-13T14:30:00.000Z"
  },
  "cryptographic_proof": {
    "instruction_hash": "sha256:a1b2c3d4...",
    "signed_by": "core_settlement_ed25519_key",
    "signature": "sig_01HXYZ...",
    "chain_reference": "L6_commitment_hash"
  }
}

Transaction transitions: authorized → settling (T20).

Instruction types: collect (buyer → escrow), authorize (hold), capture (hold → escrow), disburse (escrow → seller), margin_hold, margin_release, refund, fee, void. See SETTLEMENT_RAILS.md Section 2.2.

Proof of settlement (returned by rail):

The rail returns a verifiable, non-repudiable proof confirming funds moved as instructed. Core verifies the proof before advancing the clearing lifecycle (Principle 2.15):

{
  "proof_id": "prf_stl_01HXYZ...",
  "instruction_id": "stl_01HXYZ...",
  "status": "confirmed",
  "rail": "rtp",
  "settlement_details": {
    "amount_settled": "381.49",
    "currency": "USD",
    "settled_at": "2026-04-13T14:30:05.000Z",
    "finality_type": "irrevocable",
    "finality_achieved_at": "2026-04-13T14:30:05.000Z"
  },
  "external_references": {
    "rail_transaction_id": "RTP20260413143005ABC",
    "rail_confirmation_code": "CONF-789012"
  },
  "verification": {
    "method": "rail_signature",
    "signature": "rail_sig_01HXYZ..."
  }
}

Proof verification (5 checks):

  1. Signature — verified against rail’s published public key
  2. Amount — amount_settled must match instruction exactly
  3. Correlation — instruction_id and idempotency_key must match
  4. Finality — finality_type must be irrevocable (provisional finality holds at settling)
  5. Timeliness — proof must arrive within clearing window

Reserve Manager creates a margin hold entry in the reserve ledger upon confirmed settlement.

Transaction transitions: settling → settled (T21).

Per-rail finality definitions:

Rail Finality type Latency Notes
RTP Irrevocable Seconds Credit transfer final on confirmation
FedNow Irrevocable Seconds Settles in central bank money
Stablecoin (USDC) Irrevocable ~3 min (mainnet), seconds (L2) After confirmation threshold (12 blocks mainnet, 1 block L2)
Card (Stripe) Provisional T+1 to T+2 Subject to chargeback for 120 days. Higher risk margin applied.
ACH Provisional Same-day to T+1 Return window: 2 banking days (60 days for unauthorized)

Exception handling: Settlement failures return the clearing lifecycle to authorized state for retry or cancellation. See SETTLEMENT_RAILS.md Section 6 for the full exception taxonomy.

10.7.4 Post-Settlement Lifecycle

After settlement:

  1. Fulfillment tracking. Beacon reports delivery. Transaction transitions: settled → fulfilled (T22).
  2. Dispute window. The negotiated dispute_term_days begins counting from fulfillment date. During this window, either party may file a dispute (Section 11).
  3. Clearing. When the dispute window expires without a dispute, the Reserve Manager releases the margin hold (minus clearinghouse fees). Transaction transitions: fulfilled → cleared (T23) or completed → cleared (T24).

10.7.5 Clearing Status Endpoint

Scout or Beacon can check clearing status at any time:

GET /v1/transactions/{transaction_id}/clearing

Response (200 OK):

{
  "clearing_id": "clr_01HXYZ...",
  "transaction_id": "txn_01HXYZ...",
  "clearing_status": "settled",
  "risk_score": 0.0850,
  "beacon_risk_score": 0.0400,
  "scout_risk_score": 0.1200,
  "reserve_margin_pct": 0.0250,
  "reserve_margin_amount_usd": 9.54,
  "consent_tier": "explicit",
  "payment_method": "stablecoin_usdc",
  "dispute_term_days": 30,
  "dispute_term_expires_at": "2026-02-16T10:35:00Z",
  "authorized_at": "2026-01-14T10:35:15Z",
  "settled_at": "2026-01-14T10:35:25Z",
  "cleared_at": null
}

11. Dispute Resolution Protocol

A protocol that allows commitments without recourse invites defection. Every market that scaled beyond trusted counterparties did so by building enforcement into the structure — from the Buttonwood Agreement to modern futures clearing to eBay’s evolution from direct buyer-seller to governed marketplace. This section defines how AURA enforces promises at the protocol level.

11.1 Design Principles

  1. Protocol-native evidence. The evidence for dispute resolution is already in the protocol: signed offers, cryptographic commitment proofs, session state transitions, fulfillment records, authority attestations, and interpretation attestations. Disputes are resolved from protocol data, not reconstructed from external sources.

  2. Both parties can initiate. Either the Scout’s principal or the Beacon’s principal can raise a dispute. A buyer who receives the wrong product and a seller who doesn’t receive payment have equal standing.

  3. Frozen state. A disputed transaction is frozen. No fulfillment or payment status changes are permitted until resolution. This prevents a party from rushing to complete a transaction while a dispute is pending.

  4. Time-bounded. Disputes have filing windows and resolution deadlines. A completed transaction can only be disputed within the dispute window. Resolution must occur within the arbitration deadline or escalates.

  5. Structured outcomes. Resolution produces a structured record: outcome, evidence considered, remedial actions, and the adjudicator’s identity. This feeds reputation and, in the clearinghouse model (ROADMAP.md Phase 7), triggers reserve payouts.

11.2 Dispute Lifecycle

Transaction (committed/fulfilled/completed)
    │
    ▼
POST /transactions/:id/disputes  ──▶  disputed
    │                                      │
    │  ┌───────────────────────────────────┤
    │  │                                   │
    │  ▼                                   ▼
    │  Evidence submission            Dispute withdrawn
    │  (both parties)                 (initiator only,
    │  POST /disputes/:id/evidence    before counterparty
    │  │                              submits evidence)
    │  ▼                                   │
    │  Adjudication                        ▼
    │  POST /disputes/:id/resolve     *previous state*
    │  │
    │  ▼
    │  resolved
    │  (outcome: upheld | rejected | partial)

11.3 Filing a Dispute

POST /v1/transactions/{transaction_id}/disputes

Request:

{
  "reason": "product_not_as_described",
  "description": "Received WH-1000XM4 instead of the committed WH-1000XM5. Model number on box and device does not match the offer.",
  "category": "fulfillment",
  "evidence": [
    {
      "type": "text",
      "description": "Photo description — box label shows WH-1000XM4",
      "content": "The shipping label and product box both show model WH-1000XM4. The committed offer specified WH-1000XM5."
    }
  ],
  "requested_resolution": "replacement_or_refund"
}
Field Required Description
reason Yes Structured reason code (see 11.3.1)
description Yes Free-text description of the dispute. Max 2000 characters
category Yes Dispute category: fulfillment, payment, product_quality, authorization, other
evidence No Initial evidence items (see Section 11.5)
requested_resolution No What the initiator seeks: refund, replacement_or_refund, partial_refund, fulfillment_completion, other

Response (201 Created):

{
  "dispute_id": "dsp_01HXYZ...",
  "transaction_id": "txn_01HABC...",
  "status": "open",
  "filed_by": {
    "principal_id": "prn_01HBUYER...",
    "role": "scout_principal"
  },
  "filed_at": "2026-04-10T14:00:00Z",
  "evidence_deadline": "2026-04-17T14:00:00Z",
  "resolution_deadline": "2026-04-24T14:00:00Z",
  "session_status_before_dispute": "committed",
  "protocol_evidence_attached": true
}

On filing, Core automatically:

  1. Transitions the session to disputed (T13/T14/T15)
  2. Freezes the transaction — rejects any PUT /transactions/:id/fulfillment or PUT /transactions/:id/payment until resolved
  3. Attaches protocol evidence automatically (see Section 11.4)
  4. Notifies the counterparty via webhook (transaction.disputed event)
  5. Starts the evidence deadline clock (default: 7 days, configurable per deployment)

11.3.1 Dispute Reason Codes

Code Category Description
product_not_as_described fulfillment Product received does not match the committed offer
product_not_received fulfillment Product was not delivered within the committed timeframe
product_damaged fulfillment Product arrived damaged
wrong_quantity fulfillment Quantity received does not match committed quantity
unauthorized_transaction authorization Principal did not authorize this transaction
exceeded_delegation_scope authorization Agent committed outside its delegation scope
payment_not_received payment Beacon has not received payment for a committed transaction
payment_amount_incorrect payment Payment amount does not match committed terms
duplicate_charge payment Principal was charged more than once for the same transaction
offer_terms_changed fulfillment Terms changed between offer acceptance and fulfillment
other other Reason not covered by standard codes. description field required

11.4 Automatic Protocol Evidence

When a dispute is filed, Core automatically compiles and attaches the protocol evidence chain for the transaction. This is the structural advantage of a neutral broker — the evidence already exists in the protocol record.

Automatically attached evidence:

Evidence Item Source What It Proves
Original natural language intent Session record What the buyer actually asked for
Interpretation attestation Section 6.6 How Core interpreted the intent (model version, confidence)
Committed offer (full object) Offer record What the Beacon offered (product, price, delivery, terms)
Offer signature Section 8.2 That the Beacon signed the offer
Authority attestation Section 3.3.3 Under what authority the agent committed (consent tier, delegation scope, principal approval)
Commit request Transaction record The exact commit including buyer identity, payment method, consent
Principal identities Section 3.2.5 Who the buyer and seller are (verification levels)
Fulfillment status history Transaction record All fulfillment status updates with timestamps
Payment status history Transaction record All payment status updates with timestamps
Webhook delivery log Webhook dispatcher Whether the Beacon was notified of the commitment and when

This evidence chain is immutable. Neither party can alter it after the dispute is filed. The chain traces from human intent through machine interpretation through offer through commitment through fulfillment — every step signed and timestamped.

11.5 Evidence Submission

Both parties may submit additional evidence during the evidence window.

POST /v1/disputes/{dispute_id}/evidence

Request:

{
  "items": [
    {
      "type": "text",
      "description": "Tracking information confirming delivery of correct item",
      "content": "FedEx tracking 794644790301 shows delivery of WH-1000XM5 (SKU: WH1000XM5/B) on 2026-04-08."
    },
    {
      "type": "document_reference",
      "description": "Shipping manifest from warehouse",
      "reference_url": "https://acme.example.com/manifests/ORD-12345.pdf",
      "hash": "sha256:abc123..."
    },
    {
      "type": "external_record",
      "description": "Carrier delivery confirmation",
      "source": "fedex",
      "reference_id": "794644790301"
    }
  ]
}

Evidence types:

Type Description
text Free-text statement with description. Max 5000 characters per item
document_reference Reference to an external document. URL + content hash for integrity verification
external_record Reference to a record in an external system (carrier, payment processor, etc.)
protocol_record Reference to another AURA protocol record (another transaction, session, or agent record)

Evidence window: Both parties have until evidence_deadline to submit evidence. After the deadline, no new evidence is accepted. The evidence deadline can be extended once by either party (max 7-day extension), requiring counterparty notification.

11.6 Dispute Resolution

POST /v1/disputes/{dispute_id}/resolve

Request:

{
  "outcome": "upheld",
  "resolution": {
    "action": "refund",
    "refund_amount": 349.99,
    "refund_currency": "USD",
    "reason": "Product delivered does not match committed offer. Protocol evidence confirms offer specified WH-1000XM5; fulfillment records and buyer evidence indicate WH-1000XM4 was delivered."
  },
  "evidence_considered": [
    "protocol_chain",
    "buyer_evidence_001",
    "seller_evidence_001"
  ],
  "reputation_impact": {
    "beacon_principal": {
      "fulfillment_reliability": -0.02,
      "offer_accuracy": -0.05
    },
    "scout_principal": null
  },
  "adjudicator": {
    "type": "core_automated",
    "rule_applied": "offer_product_mismatch_with_evidence"
  }
}
Field Required Description
outcome Yes upheld (dispute valid, in favor of initiator), rejected (dispute invalid, in favor of respondent), partial (both parties bear some responsibility), withdrawn (initiator withdrew)
resolution.action Yes Remedial action: refund, partial_refund, replacement, fulfillment_completion, no_action, mutual_release
resolution.refund_amount Conditional Required when action is refund or partial_refund
resolution.reason Yes Explanation of the resolution decision. References evidence considered
evidence_considered Yes List of evidence item IDs that informed the decision
reputation_impact No Reputation dimension adjustments for each principal. Null = no impact
adjudicator.type Yes Who adjudicated: core_automated (rule-based), core_manual (human operator), clearinghouse (Phase 7 CCP), external_arbitration
adjudicator.rule_applied Conditional The specific rule or policy that produced the outcome. Required for core_automated

Resolution outcomes:

Outcome Session Transition Effect
upheld disputed → resolved Initiator’s claim validated. Remedial action enforced. Respondent’s reputation impacted
rejected disputed → resolved Initiator’s claim not supported by evidence. No remedial action. Initiator’s reputation may be impacted if dispute was frivolous
partial disputed → resolved Both parties bear responsibility. Partial remedial action (e.g., partial refund). Both parties’ reputations may be adjusted
withdrawn disputed → previous state Initiator withdrew before resolution. No remedial action. Transaction returns to pre-dispute state (T17)

11.7 Dispute Window and Deadlines

Parameter Default Configurable Description
dispute_window 30 days Per deployment Time after completed_at during which a dispute can be filed on a completed transaction. Disputes on committed or fulfilled transactions have no window — they can be filed at any time while in those states
evidence_deadline 7 days Per dispute Time after dispute filing for both parties to submit evidence
evidence_extension 7 days Once per party Maximum extension to the evidence deadline. Requires notification
resolution_deadline 14 days Per deployment Time after evidence deadline closes for adjudication to complete. If exceeded, escalates to manual review

11.8 Clearinghouse Dispute Resolution (Phase 7)

When the clearinghouse is operational, dispute resolution gains financial enforcement backed by the risk reserve system (CLEARINGHOUSE.md Sections 3.3, 3.7).

11.8.1 Clearinghouse-Operated Adjudication

The clearinghouse adjudicator (adjudicator.type: "clearinghouse") resolves disputes using the protocol evidence chain plus financial data:

Step 1: Dispute filed.

Step 2: Automatic adjudication (clear-cut cases).

Core uses protocol evidence to auto-adjudicate unambiguous cases:

Dispute Type Evidence Checked Auto-Resolution
Product not as described Committed offer (product, attributes) vs. fulfillment record If mismatch provable from protocol data → upheld
Payment not received Settlement confirmation from escrow/rail If settlement confirmed on-chain/by-processor → rejected
Unauthorized settlement Authority attestation (Section 3.3.3), delegation scope If commitment outside scope → upheld
Non-delivery Fulfillment record, delivery SLA from offer terms If SLA exceeded with no delivery confirmation → upheld

The clearinghouse has read-only access to the full protocol evidence chain and settlement confirmations to validate Core’s automated decision.

Step 3: Reserve draw (if dispute upheld).

When a dispute is upheld:

  1. Refund amount is drawn from the Beacon’s per-transaction reserve hold (reserve_ledger entry type dispute_payout).
  2. If the per-transaction hold is insufficient, the Beacon’s accumulated reserve pool covers the remainder.
  3. Scout-principal receives refund via original settlement method.
  4. Beacon’s risk profile (Section 3.1.4) is updated: dispute_upheld_rate increases, enforcement_status may escalate.

Step 4: Appeal (if requested).

Either party may appeal Core’s automated decision within 7 days of resolution:

POST /v1/disputes/{dispute_id}/appeal

{
  "grounds": "Automated resolution did not consider material evidence",
  "new_evidence": [
    {
      "type": "external_document",
      "description": "Delivery photo showing correct product delivered",
      "url": "https://..."
    }
  ]
}

Appeals are escalated to manual review. Manual review decisions are binding and final. The clearinghouse logs the appeal, the reviewer identity, and the outcome.

Step 5: Reserve release (if dispute rejected).

When a dispute is rejected:

11.8.2 Clearinghouse-Specific Dispute Reason Codes

In addition to the existing reason codes (Section 11.3), the clearinghouse introduces:

Code Category Description
settlement_failed payment Settlement was not completed despite clearing authorization
unauthorized_settlement authorization Payment was processed without valid authority attestation
reserve_not_held payment Clearinghouse did not hold the required reserve margin
settlement_escrow_not_released fulfillment Escrow was not released to Beacon despite confirmed delivery

11.8.3 Reserve-to-Risk Feedback Loop

Dispute outcomes close the economic feedback loop described in MARKET_ECONOMICS.md:

Dispute filed → Adjudicated →
  [Upheld] → Reserve draw → Reputation degradation →
    Higher risk margins → Reduced competitiveness →
    Incentive to improve behavior or exit
  [Rejected] → Reserve maintained → Reputation unchanged →
    No margin impact

This loop is the financial embodiment of the cooperative equilibrium from MARKET_ECONOMICS.md Section 6. The clearinghouse doesn’t need to convince agents to behave — it prices behavior, and rational agents converge on the efficient outcome.

11.8.4 Graduated Dispute Escalation

Instead of binary dispute filing, the clearinghouse supports early-warning and negotiation mechanisms to reduce frivolous disputes and encourage direct resolution:

Level 1: Informal Notice (24-hour response window)

Either party can file an informal notice requesting direct contact:

POST /v1/transactions/{transaction_id}/notice

{
  "issue": "product_not_as_described",
  "severity": "minor",
  "resolution_requested": "clarification",
  "description": "Color received was midnight blue, not black as listed"
}

The counterparty receives a webhook and has 24 hours to respond. If the response resolves the issue, the transaction continues normally. If not, the party can escalate to a formal dispute. Informal notices do NOT freeze the transaction, do NOT draw reserves, and are NOT visible to the clearinghouse unless escalated.

Level 2: Formal Dispute (as defined in Section 11.3)

If the informal notice is unresolved, either party can escalate to a formal dispute. Transaction is frozen. Evidence deadline starts. Full adjudication process applies.

Level 3: Clearinghouse Adjudication (Section 11.8.1)

Automated or manual resolution with financial enforcement.

Escalation metrics:

The clearinghouse tracks the escalation ratio per principal:

11.8.5 Protocol Minimum Enforcement for Disputes

AURA enforces minimum protection periods at the protocol level, regardless of what either party prefers. These minimums exist because markets without recourse drive out reliable participants (MARKET_ECONOMICS.md Section 4 — adverse selection).

Mandatory minimums (Core-enforced, cannot be waived):

Protection Minimum Enforcement
Dispute window 7 days from delivery/completion Core rejects offers with dispute_window_days < 7. If Beacon submits below-floor value, Core raises to minimum and logs a policy violation.
Return policy transparency Must be declared on offer Core rejects offers with missing return_policy_days in payment_terms.

Recommended defaults (configurable per deployment):

Protection Recommended Notes
Dispute window 30 days Matches consumer protection norms in most jurisdictions
Return policy 14 days Aligns with EU consumer rights directive

Protocol minimum violations: When a Beacon submits an offer below a protocol minimum, Core:

  1. Raises the value to the minimum
  2. Logs a policy violation to the clearing audit trail
  3. Notifies the Beacon that the value was adjusted
  4. Tracks the violation for risk scoring (repeated violations → enforcement escalation)

The offer is still valid — the minimum is applied transparently, not punitively. But persistent attempts to circumvent minimums are treated as an adverse signal in risk assessment.

11.9 Retrieving Dispute Details

GET /v1/disputes/{dispute_id}
GET /v1/transactions/{transaction_id}/disputes
GET /v1/principals/{principal_id}/disputes

These endpoints return the full dispute record including status, evidence from both parties, protocol evidence chain, resolution (if resolved), and timeline. Access is restricted to the transaction’s principals, their agents, and (in Phase 7) the clearinghouse.

11.10 Intent-to-Commitment Chain of Custody

The dispute resolution protocol relies on evidence. The evidence is only as strong as the chain linking each step. This section defines the intent chain — a single, immutable, cryptographically linked record that traces a transaction from the human’s original signal through every transformation to the final commitment and outcome.

The intent chain is the protocol’s answer to Principle 7 from “Where Agents Meet”: the protocol serves human interests through machine operations. Machines execute, but the chain proves that what was executed traces back to what a human intended, through every intermediate step, with each handoff signed and attributable.

Every committed transaction produces an intent chain comprising up to seven links. Each link is signed by the party responsible for that step. The chain is assembled by Core at commit time and stored as an immutable transaction artefact.

Link Name Who Signs What It Proves Source
L1 Principal Signal Scout agent The Scout received this input from its principal and forwarded it faithfully to Core. Includes the raw text and the channel through which it was received Scout SDK at session creation
L2 Interpretation Core Core transformed the raw input into structured requirements using a specific model. The input and output are bound by Core’s signature Section 6.6 Interpretation Attestation
L3 Principal Review Scout agent The principal was presented with the interpretation and did not object, OR the principal was not consulted (declared). Captures whether the human saw what the machine understood Scout SDK after interpretation returned
L4 Offer Selection Scout agent The agent selected this specific offer from the available set. Records the selection criteria, the alternatives considered, and whether the principal reviewed the offers Scout SDK at offer selection
L5 Principal Consent Scout agent or principal The principal consented to this specific commitment. For explicit consent: the principal signed. For policy consent: the policy rule is cited. For delegated consent: the delegation scope is cited Section 3.3 Authority Attestation
L6 Commitment Core Core executed the atomic commit, creating the transaction. Core’s counter-signature confirms the commit was valid, the authority was verified, and the transaction was recorded Core at commit processing
L7 Outcome Core Terminal state — fulfillment and payment status, or dispute resolution outcome. Closes the chain Core at transaction completion or dispute resolution

11.10.2 Intent Chain Object

The intent chain is assembled incrementally as the session progresses. Each link is added when the corresponding event occurs. The complete chain is retrievable as a single artefact.

GET /v1/transactions/{transaction_id}/intent-chain

Response:

{
  "transaction_id": "txn_01HXYZ...",
  "chain_id": "ich_01HXYZ...",
  "chain_status": "complete",
  "links": [
    {
      "link": "L1",
      "name": "principal_signal",
      "timestamp": "2026-04-01T10:30:00Z",
      "signed_by": "sct_01H...",
      "signer_type": "scout_agent",
      "payload": {
        "raw_input": "I need noise-cancelling headphones for the office, under $400, by next week",
        "input_channel": "mcp_claude_desktop",
        "input_language": "en",
        "scout_sdk_version": "0.2.0",
        "principal_id": "prn_01HBUYER..."
      },
      "signature": "base64-ed25519-sig-L1",
      "previous_link_hash": null
    },
    {
      "link": "L2",
      "name": "interpretation",
      "timestamp": "2026-04-01T10:30:01Z",
      "signed_by": "core_01H...",
      "signer_type": "core",
      "payload": {
        "session_id": "ses_01HABC...",
        "interpretation_attestation_ref": "att_01H...",
        "structured_output_hash": "sha256:def456...",
        "model_id": "aura-intent-v2.1",
        "confidence": 0.94
      },
      "signature": "base64-ed25519-sig-L2",
      "previous_link_hash": "sha256:abc123..."
    },
    {
      "link": "L3",
      "name": "principal_review",
      "timestamp": "2026-04-01T10:30:05Z",
      "signed_by": "sct_01H...",
      "signer_type": "scout_agent",
      "payload": {
        "interpretation_presented_to_principal": true,
        "presentation_method": "conversational_summary",
        "principal_response": "acknowledged",
        "modifications_requested": false,
        "principal_review_duration_ms": 3200
      },
      "signature": "base64-ed25519-sig-L3",
      "previous_link_hash": "sha256:bcd234..."
    },
    {
      "link": "L4",
      "name": "offer_selection",
      "timestamp": "2026-04-01T10:35:00Z",
      "signed_by": "sct_01H...",
      "signer_type": "scout_agent",
      "payload": {
        "selected_offer_id": "ofr_01HABC...",
        "offers_presented_to_principal": 3,
        "offers_total_received": 5,
        "selection_method": "principal_choice",
        "principal_saw_offer_details": true,
        "selection_criteria": "principal selected AudioPro based on fastest delivery",
        "alternatives_summary": [
          {"offer_id": "ofr_01HDEF...", "merchant": "TechMart", "price": 348.00, "reason_not_selected": "slower delivery"},
          {"offer_id": "ofr_01HGHI...", "merchant": "OfficeBuy", "price": 299.00, "reason_not_selected": "principal preferred Bose brand"}
        ]
      },
      "signature": "base64-ed25519-sig-L4",
      "previous_link_hash": "sha256:cde345..."
    },
    {
      "link": "L5",
      "name": "principal_consent",
      "timestamp": "2026-04-01T10:35:15Z",
      "signed_by": "sct_01H...",
      "signer_type": "scout_agent",
      "payload": {
        "consent_tier": "explicit",
        "delegation_scope_id": "dsc_01HXYZ...",
        "principal_approval_ref": "approval object or null",
        "consent_evidence": "principal confirmed 'Go with AudioPro' in conversation",
        "amount_consented": 379.00,
        "currency": "USD"
      },
      "signature": "base64-ed25519-sig-L5",
      "previous_link_hash": "sha256:def456..."
    },
    {
      "link": "L6",
      "name": "commitment",
      "timestamp": "2026-04-01T10:35:16Z",
      "signed_by": "core_01H...",
      "signer_type": "core",
      "payload": {
        "transaction_id": "txn_01HXYZ...",
        "offer_id": "ofr_01HABC...",
        "authority_verified": true,
        "delegation_scope_verified": true,
        "principal_approval_verified": true,
        "amount": 379.00,
        "currency": "USD",
        "scout_principal_id": "prn_01HBUYER...",
        "beacon_principal_id": "prn_01HSELLER..."
      },
      "signature": "base64-ed25519-sig-L6",
      "previous_link_hash": "sha256:efg567..."
    },
    {
      "link": "L7",
      "name": "outcome",
      "timestamp": "2026-04-12T09:00:00Z",
      "signed_by": "core_01H...",
      "signer_type": "core",
      "payload": {
        "terminal_state": "completed",
        "fulfillment_status": "delivered",
        "fulfillment_reference": "FDX794644790301",
        "payment_status": "charged",
        "payment_reference": "stripe_pi_01H...",
        "dispute_filed": false
      },
      "signature": "base64-ed25519-sig-L7",
      "previous_link_hash": "sha256:fgh678..."
    }
  ],
  "chain_hash": "sha256:final_chain_hash...",
  "chain_signature": "base64-ed25519-core-signature-over-chain-hash"
}

11.10.3 Cryptographic Linking

Each link includes a previous_link_hash — the SHA-256 hash of the preceding link’s canonical JSON (including its signature). This creates a hash chain analogous to a blockchain or git commit history: tampering with any link invalidates every subsequent hash.

The final chain_hash is the hash of the complete chain. Core signs this hash, producing a single signature that attests to the integrity of the entire chain. Any party with Core’s public key can verify that the chain is complete and unmodified.

Verification algorithm:

  1. For each link L(n) where n > 1: compute SHA-256 of L(n-1)’s canonical JSON. Verify it matches L(n).previous_link_hash
  2. Verify each link’s signature against the signed_by party’s public key
  3. Compute SHA-256 of the complete chain. Verify it matches chain_hash
  4. Verify chain_signature against Core’s public key

If any verification fails, the chain is compromised. The specific failing link identifies where the chain broke — which party’s attestation is invalid or which handoff was tampered with.

11.10.4 Principal Review Attestation (L3) — Design Notes

L3 is the most critical link for human accountability. It answers: did the human see what the machine understood?

Three states are possible:

principal_response Meaning Risk Implication
acknowledged Principal was shown the interpretation and did not object Standard — principal had opportunity to correct
modified Principal saw the interpretation and requested changes (which were applied before proceeding) Lower risk — principal actively engaged with interpretation
not_consulted Principal was not shown the interpretation. Agent proceeded under delegated authority Higher risk — no human verification of interpretation accuracy. Consent tier must be policy or delegated

Consistency enforcement: If L3 declares principal_response: "not_consulted" but L5 declares consent_tier: "explicit", Core rejects the commit as inconsistent. Explicit consent requires that the principal was consulted at some point before commitment.

Scout SDK responsibility: The Scout SDK is responsible for producing L1, L3, L4, and L5. The protocol defines the schema; the SDK implements the collection. A Scout SDK that always declares principal_review.interpretation_presented_to_principal: true without actually presenting it is making a false attestation — which is detectable if the principal later disputes that they were never shown the interpretation. The attestation creates accountability, not enforcement. The dispute resolution protocol (Section 11) makes false attestations consequential.

11.10.5 Offer Selection Attestation (L4) — Design Notes

L4 answers: how and why was this specific offer chosen?

Two selection methods are supported:

selection_method Description
principal_choice The principal reviewed offers and chose one. The agent may have ranked or summarised, but the human made the selection
agent_autonomous The agent selected the offer autonomously under delegated authority. The principal did not review individual offers

For agent_autonomous, the selection_criteria field must describe the algorithm or logic the agent used. This is the evidence a dispute reviewer examines if the principal claims the agent chose poorly.

The alternatives_summary field records what other options existed and why they were not selected. This prevents a scenario where a dispute reviewer sees only the committed offer and cannot assess whether better options were available. It also provides evidence if a Scout is accused of consistently selecting offers from a specific Beacon (potential collusion signal for reputation scoring).

11.10.6 Chain Assembly and Timing

Links are assembled incrementally:

Core validation at L6 (commit): Core verifies the chain before counter-signing:

  1. L1 exists and is signed by the committing Scout
  2. L2 exists and matches the session’s interpretation attestation
  3. L3 exists and is consistent with the declared consent tier
  4. L4 exists and references the offer being committed
  5. L5 exists and the authority attestation (Section 3.3.3) is valid
  6. All previous_link_hash values form a valid hash chain

If validation fails, the commit is rejected with a structured error identifying the broken link. This is a hard gate — no transaction is created without a complete, valid chain from L1 through L5.

11.10.7 Chain Accessibility

Accessor Links Visible When
Scout principal All (L1–L7) Always — the chain is the principal’s record of what their agent did on their behalf
Beacon principal L2 (interpretation, redacted raw input), L4 (offer selection, redacted alternatives), L6, L7 After commit — Beacon sees what was interpreted and what was committed, not the raw human input or the full alternatives
Dispute adjudicator All (L1–L7) During dispute — full chain available for evidence review
Clearinghouse All (L1–L7) Phase 7 — for risk assessment and audit

Privacy preservation: The Beacon’s view of the chain redacts L1’s raw_input (replaced with [redacted — available in dispute]) and L4’s alternatives_summary (competitive intelligence). The full chain is visible only to the Scout’s principal and to dispute/clearinghouse processes. This maintains the identity abstraction and information sovereignty described in MARKET_ECONOMICS.md Sections 8.1–8.3.