aura-labs.ai

AURA Clearinghouse Architecture

Document Purpose: Detailed architecture for the protocol-native clearinghouse (Central Counterparty) that validates, settles, and enforces financial obligations between Scout and Beacon agents. Owner: Marc Massar, AURA Labs Version: 1.1 Last Updated: April 14, 2026 Protocol: v2.2 Status: Architecture Designed (Phase 7) Authority: DEC-034 (Clearinghouse Model), DEC-043 (Clearinghouse Architecture) References: MARKET_ECONOMICS.md, ROADMAP.md Phase 7, NEUTRAL_BROKER.md Section 4.5, PROTOCOL_SPECIFICATION.md v2.2

1. Introduction

1.1 What the Clearinghouse Is

The clearinghouse is the financial layer of AURA Core. It sits between the commitment of a transaction and the movement of money, performing four functions:

  1. Clearing — Validating that both sides of a transaction can perform: buyer can pay, seller can deliver. Verifying amounts, consent, authority. Computing bilateral risk. This happens before money moves.
  2. Settlement — The actual movement of money between parties via a payment rail. Settlement is rail-specific (stablecoin transfer, bank transfer, card charge).
  3. Risk reserve management — Holding funds to cover future disputes for the duration of the negotiated dispute/return window, then releasing to the Beacon minus fees.
  4. Financial enforcement — When disputes are upheld, paying from the risk reserve. When rejected, releasing the hold.

1.2 What the Clearinghouse Is Not

1.3 Critical Distinction: Clearing vs. Settlement

Clearing is pre-settlement validation. Settlement is actual money movement. These are architecturally separate concerns with different failure modes, different timing, and different governance. The clearinghouse performs both, through distinct sub-components (Section 3).

1.4 Design Authority

This architecture is grounded in:

2. Terminology

Term Definition in AURA Context
Clearing Validating that both sides of a transaction can perform. Verifying amounts, consent, authority. Computing risk. Happens before money moves.
Settlement The actual movement of money between parties via a payment rail. Rail-specific (stablecoin, bank transfer, card).
Risk reserve Funds held to cover future disputes. Held for the duration of the dispute/return window negotiated in the offer terms, then released to the Beacon minus fees.
Risk margin The percentage of transaction value held in the risk reserve. Computed from the bilateral risk score.
Clearing window The time between commitment and settlement confirmation.
Dispute term The negotiated period after fulfillment during which disputes/returns are accepted. Determines how long the risk reserve is held.
Business rule A binary pass/fail policy configured by a Beacon. Evaluated before risk scoring. Not overridable by risk scores or margin adjustments.
Protocol minimum A floor value enforced by Core that neither party can waive (e.g., minimum 7-day dispute window). Derives from MARKET_ECONOMICS.md market design principles.
Loss waterfall The sequence of funds tapped when a dispute is upheld: transaction margin, then Beacon reserve, then pooled reserve, then operator fund.
Custody model How funds are held: regulated subsidiary, third-party custodian, or smart contract escrow. A deployment configuration, not a per-transaction choice.

3. Component Architecture

The clearinghouse comprises eight sub-components within a single domain boundary. Each has a distinct responsibility and governance model.

3.1 Business Rules Gate

Purpose: Binary pass/fail evaluation of Beacon-configured policies. Runs BEFORE risk assessment.

Characteristics:

Rule types:

Clearing sequence position:

Commit → Business Rules Gate (hard stops) →
  [PASS] → Risk Assessment →
    [WITHIN TOLERANCE] → Margin Computation → Settlement → ...
    [ABOVE BEACON THRESHOLD] → Decline (soft, Beacon preference)
  [FAIL] → Reject (hard stop, 403, structured reason)

Why this is separate from risk: Every real-world clearinghouse separates admission/qualification gates from runtime risk assessment. DTCC has a Rules & Standards committee for gates and a separate Risk Management unit for scoring. CME requires FCM registration (gate) AND computes SPAN margins (risk). Visa requires PCI-DSS compliance (gate) AND monitors transaction velocity (risk). A Scout with a perfect risk score is still rejected if they fail a gate.

3.2 Risk Engine

Purpose: Bilateral risk assessment on every transaction. No opt-in, no threshold gate.

Risk is computed from BOTH sides of the transaction:

Beacon (seller) risk inputs:

Scout (buyer) risk inputs:

Transaction-level inputs:

B2B-specific risk inputs (required for B2B clearing enablement):

These inputs are stored in the risk_inputs JSONB snapshot (no schema changes required) and are gated: the B2B flow (Section 4.2) must not go live without them.

Output: Composite risk score (0.0-1.0), broken into beacon_risk, scout_risk, and transaction_risk components, plus risk margin percentage and amount.

Beacon visibility: The buyer-side risk score is exposed to the Beacon (without revealing buyer identity). Beacons can configure auto-decline thresholds — e.g., “decline transactions where buyer risk score > 0.7” or “require explicit consent for buyer risk > 0.5”. This gives sellers control over who they transact with, based on verifiable risk signals rather than identity.

Configurable floor: Transactions below a configurable value threshold use a floor risk margin (e.g., 1%) rather than computing a full risk score. This avoids overhead on micro-transactions while still collecting reserve.

Formula approach (per DEC-043): Hybrid — formula structure and bounds published in protocol spec (immutable); tunable parameters (category weights, tier multipliers) in operational documentation with notice period. Deterministic and auditable — published formula, not ML black box.

3.3 Reserve Manager

Purpose: Track per-Beacon risk reserves and per-transaction margin allocations.

Operations:

Term-based holds: Each reserve hold has an expiry tied to the offer’s dispute/return terms. The Beacon negotiates these terms in the offer (e.g., “30-day return window”). The clearinghouse holds the reserve for that duration.

Accounting model: Double-entry ledger. Every movement is a ledger entry — every debit has a corresponding credit. An auditor can verify reserve balances at any point in time by replaying ledger entries. The sum of all debits equals the sum of all credits (always).

3.4 Settlement Orchestrator

Purpose: Translate clearing decisions into settlement instructions for the configured payment rail.

Primary model: Real-time atomic settlement. Stablecoin/programmatic wallet settlement is the architecture’s default. Settlement flows toward continuous real-time processing, not gated batches.

Payment timing determined by offer terms and payment method:

Scenario Settlement Timing Mechanism
Atomic (stablecoin/wallet) Immediate at commit Smart contract holds risk reserve for dispute term
B2C physical goods Wallet authorization at commit, capture at fulfillment Two-phase settlement
B2C digital goods Settlement at commit Immediate delivery justifies immediate payment
B2B negotiated terms Per agreed terms (Net 30, Net 60, milestone) Invoice-driven, term tracking
Legacy card Auth hold at commit, capture at fulfillment Transitional adapter

Batch netting: optional optimization. Available for participants who choose it (e.g., high-frequency B2B principals reducing per-transaction costs). Not the default flow. In stablecoin/programmatic wallet scenarios, atomic per-transaction settlement is economically viable — smart contracts enforce terms at the transaction level.

Rail adapters (initial set):

Idempotency: Settlement instructions are keyed to transaction IDs. Duplicate instructions are safely ignored.

3.5 Clearing Lifecycle Manager

Purpose: Orchestrate the clearing sequence per transaction via a state machine.

State machine on clearing_transactions:

pending → risk_assessed → authorized → settling → settled →
  [dispute_term_active] → cleared
                                       ↘ disputed → resolved → cleared

stateDiagram-v2
    [*] --> pending : Transaction committed
    pending --> risk_assessed : Risk engine completes bilateral assessment
    risk_assessed --> authorized : Payment pre-approved, business rules pass
    authorized --> settling : Settlement instruction submitted to rail
    settling --> settled : Settlement confirmed by rail
    settled --> dispute_term_active : Fulfillment confirmed, dispute window opens
    dispute_term_active --> cleared : Dispute window expires, no dispute filed
    dispute_term_active --> disputed : Dispute filed during window
    disputed --> resolved : Adjudication complete
    resolved --> cleared : Reserve released or drawn per outcome
    cleared --> [*]

    settling --> failed : Settlement fails
    failed --> authorized : Retry (idempotent)

Timeout handling: If settlement doesn’t confirm within the clearing window, the Lifecycle Manager escalates — retry, alert, or rollback depending on the rail adapter’s capabilities.

Integration: The clearing state machine extends the existing transaction state machine via a clearing_status column on the transactions table. The session-level state machine (Section 4.5 of PROTOCOL_SPECIFICATION.md) gains corresponding states.

3.6 Margin Calculator

Purpose: Compute risk margin from risk score plus adjustments.

Adjustment factors:

Factor Effect Rationale
Consent tier explicit (lowest), policy (medium), delegated (highest) Per DEC-040 and ROADMAP Phase 7 consent tiers — higher consent ambiguity = wider dispute surface
Category risk Configurable per product category Electronics have different dispute profiles than commodities
Beacon history New Beacons with insufficient history → floor margin until N clean transactions Unknown risk = conservative pricing
Payment method Instant-settlement methods may carry different risk profiles than deferred Stablecoin settlement is atomic and verifiable; credit terms carry counterparty risk
Amount tier Configurable brackets Higher amounts may warrant higher margins
Cross-border Elevated margin for cross-jurisdiction transactions Enforcement complexity increases

Formula governance: Structure and bounds published in protocol spec. Parameter values (category weights, tier multipliers, bracket thresholds) in operational documentation with notice period. This is the hybrid approach per DEC-043.

3.7 Clearinghouse Adjudicator

Purpose: Extend existing dispute resolution (disputes.js, PROTOCOL_SPECIFICATION.md Section 11) with financial enforcement.

Adjudicator type: clearinghouse (Protocol Spec Section 11.8)

Operations:

Evidence basis: Uses the protocol evidence chain (intent chain L1-L7, signed offers, fulfillment records, commitment proofs). Same evidence, financial consequences.

Graduated escalation (Section 6.3): The adjudicator supports three escalation levels — informal notice, formal dispute, and clearinghouse adjudication — before reserve draws occur.

3.8 Custody Adapter Layer

Purpose: Abstract the fund-holding mechanism behind a common interface.

The platform supports multiple custody models — the architecture does not assume a single model:

Model Description Trade-offs
Regulated subsidiary AURA Labs entity holds funds in bank accounts Direct control, full regulatory burden
Third-party custodian Banking-as-a-service provider (e.g., Synapse, Column, Modulr) Shared regulatory burden, faster launch
Smart contract escrow On-chain programmatic escrow Transparent, trustless, crypto-native rails only

Common interface:

Custody routing: Multi-custody is a launch requirement for consumer-facing deployments. Participants arrive with different payment instruments — a Scout paying with USDC routes to smart contract escrow, the same Scout paying by card on a different transaction routes through regulated custody. Custody routing follows the payment method selected at clearing time, not a global deployment setting. The clearing_accounts table supports per-account custody_model for this reason.

Single-custody deployments are sufficient for market-specific contexts where all participants share a common payment rail (e.g., an all-stablecoin B2B marketplace).

Every custody operation is logged with external references for audit trail.

4. Transaction Lifecycle with Clearing

Four distinct flows depending on the transaction type. All share the same clearing infrastructure; they differ in settlement timing and escrow mechanics.

4.1 B2C Flow (Wallet Settlement at Fulfillment)

sequenceDiagram
    participant Scout
    participant Core
    participant RiskEngine
    participant Settlement
    participant Beacon

    Scout->>Core: Commit to offer
    Core->>Core: Business Rules Gate
    Core->>RiskEngine: Bilateral risk assessment
    RiskEngine-->>Core: Risk score + margin
    Core->>Settlement: Authorize wallet (hold)
    Settlement-->>Core: Authorization confirmed
    Core-->>Scout: Transaction committed (clearing=authorized)
    Note over Core: Awaiting fulfillment
    Beacon->>Core: Report fulfillment (delivered)
    Core->>Settlement: Capture wallet charge
    Settlement-->>Core: Settlement confirmed
    Core-->>Beacon: Transaction settled
    Note over Core: Dispute term active
    alt No dispute filed
        Core->>Core: Dispute window expires
        Core->>Core: Release reserve (minus fees)
        Core-->>Beacon: Transaction cleared
    else Dispute filed
        Scout->>Core: File dispute
        Core->>Core: Adjudicate (protocol evidence)
        Core->>Settlement: Reserve draw or release
        Core-->>Scout: Resolution
        Core-->>Beacon: Resolution
    end

4.2 B2B Flow (Negotiated Terms)

sequenceDiagram
    participant Scout
    participant Core
    participant RiskEngine
    participant Settlement
    participant Beacon

    Scout->>Core: Commit to offer (Net 30 terms)
    Core->>Core: Business Rules Gate
    Core->>RiskEngine: Bilateral risk assessment + credit check
    RiskEngine-->>Core: Risk score + margin
    Core-->>Scout: Transaction committed (clearing=approved)
    Beacon->>Core: Report fulfillment (delivered)
    Core->>Beacon: Invoice issued
    Note over Core: Payment term active (Net 30)
    Scout->>Core: Payment received (within terms)
    Core->>Settlement: Confirm settlement
    Settlement-->>Core: Settlement confirmed
    Note over Core: Dispute term active
    Core->>Core: Dispute window expires
    Core->>Core: Release reserve (minus fees)
    Core-->>Beacon: Transaction cleared

4.3 Agent-to-Agent Flow (Atomic Stablecoin)

This is the end-state the architecture optimizes for. As agent capabilities mature, agent economies will emerge where humans participate only at on-ramp (funding the agent’s wallet) and off-ramp (withdrawing proceeds). Settlement is atomic, escrow is programmatic, and risk assessment is the only gate between commitment and settlement.

sequenceDiagram
    participant ScoutAgent
    participant Core
    participant RiskEngine
    participant SmartContract
    participant BeaconAgent

    ScoutAgent->>Core: Commit to offer
    Core->>Core: Business Rules Gate
    Core->>RiskEngine: Bilateral risk assessment
    RiskEngine-->>Core: Risk score + margin
    Core->>SmartContract: Atomic transfer + escrow (risk reserve)
    SmartContract-->>Core: Transfer confirmed, escrow held
    Core-->>ScoutAgent: Transaction settled
    Core-->>BeaconAgent: Transaction settled
    BeaconAgent->>Core: Report fulfillment
    Note over SmartContract: Escrow held for dispute term
    alt Dispute term expires
        SmartContract->>SmartContract: Auto-release escrow
        Core-->>BeaconAgent: Transaction cleared
    else Dispute filed
        Core->>SmartContract: Escrow to adjudicator
        Core->>Core: Adjudicate
        SmartContract->>SmartContract: Distribute per outcome
    end

4.4 Legacy Card Flow (Transitional Adapter)

Commit → Business Rules Gate → Clearing (risk assessment, card auth hold) →
  Transaction (committed, clearing=authorized) →
  Fulfillment (delivered) → Settlement (card capture) →
  Transaction (settled) → [dispute term] →
  [term expires or resolved] → Reserve release →
  Transaction (cleared)

Cards are a transitional settlement method. As agents adopt wallet methods (stablecoin, programmatic wallets), card volume will migrate. The clearinghouse treats cards as one rail adapter among several, not as the default.

5. Data Model

5.1 New Tables

clearing_accounts

Column Type Description
id UUID PK Account identifier
principal_id UUID FK → principals Owner principal
account_type VARCHAR(30) risk_reserve, onboarding_deposit, operating, buyer_prefund
balance DECIMAL(15,2) Current balance
currency VARCHAR(10) Currency code
custody_model VARCHAR(30) regulated_subsidiary, third_party_custodian, smart_contract
custody_reference VARCHAR(255) External account/address reference
status VARCHAR(20) active, frozen, closed
created_at TIMESTAMPTZ  
updated_at TIMESTAMPTZ  

clearing_transactions

Column Type Description
id UUID PK Clearing transaction identifier
transaction_id UUID FK → transactions 1:1 relationship
risk_score DECIMAL(5,4) Composite score (0.0-1.0)
beacon_risk_score DECIMAL(5,4) Seller-side risk component
scout_risk_score DECIMAL(5,4) Buyer-side risk component
transaction_risk_score DECIMAL(5,4) Transaction-level risk component
risk_margin_pct DECIMAL(5,4) Margin percentage
risk_margin_amount DECIMAL(15,2) Margin amount in transaction currency
consent_tier VARCHAR(20) Consent tier at time of clearing
payment_method VARCHAR(30) Payment method used
dispute_term_days INTEGER Negotiated dispute/return window
clearing_status VARCHAR(30) See state machine (Section 3.5)
risk_inputs JSONB Snapshot of ALL bilateral inputs (auditability)
beacon_risk_config JSONB Beacon’s config at time of clearing
authorized_at TIMESTAMPTZ  
settled_at TIMESTAMPTZ  
dispute_term_expires_at TIMESTAMPTZ  
cleared_at TIMESTAMPTZ  
created_at TIMESTAMPTZ  

settlement_instructions

Column Type Description
id UUID PK Instruction identifier
clearing_transaction_id UUID FK → clearing_transactions  
direction VARCHAR(20) collect, disburse, refund, margin_hold, margin_release
amount DECIMAL(15,2)  
currency VARCHAR(10)  
rail VARCHAR(30) manual, stablecoin_usdc, card_stripe, bank_ach, bank_sepa
external_reference VARCHAR(255) Rail-specific reference
status VARCHAR(20) pending, submitted, confirmed, failed
idempotency_key UUID UNIQUE Prevents duplicate settlement
created_at TIMESTAMPTZ  
confirmed_at TIMESTAMPTZ  

reserve_ledger

Column Type Description
id UUID PK Ledger entry identifier
clearing_account_id UUID FK → clearing_accounts  
clearing_transaction_id UUID FK (nullable) Null for deposits/withdrawals not tied to a transaction
entry_type VARCHAR(30) margin_hold, margin_release, dispute_payout, deposit, withdrawal, interest, fee
debit DECIMAL(15,2) DEFAULT 0  
credit DECIMAL(15,2) DEFAULT 0  
balance_after DECIMAL(15,2) Running balance
description TEXT  
created_at TIMESTAMPTZ Database-generated

Constraints: Application role has INSERT only on reserve_ledger. No UPDATE, no DELETE. Corrections are recorded as reversal entries, not edits.

Concurrency: The balance_after column creates a serialization dependency — each entry derives from the previous entry for the same clearing account. Concurrent transactions clearing for the same Beacon would produce incorrect running balances without serialization. The required strategy: SELECT ... FOR UPDATE on the clearing_accounts row before inserting to the ledger. This pessimistic lock serializes writes per account while allowing concurrent writes across different accounts. balance_after must be computed within the same database transaction as the INSERT, never in application code before the write. The existing pattern in transactions.js (SELECT ... FOR UPDATE on sessions) establishes this as the codebase convention for concurrent-write protection.

beacon_risk_config

Column Type Description
id UUID PK  
beacon_id UUID FK → beacons  
payment_method VARCHAR(30) card, stablecoin, bank_transfer, * (wildcard default)
min_risk_margin_pct DECIMAL(5,4) Beacon’s own floor (must be >= protocol floor)
dispute_term_days INTEGER DEFAULT 30  
auto_decline_risk_score DECIMAL(5,4) Auto-decline on composite risk
max_buyer_risk_score DECIMAL(5,4) Decline based on buyer risk
require_consent_tier VARCHAR(20) Minimum consent tier (links to DEC-040)
require_trust_level VARCHAR(30) Minimum buyer verification
fraud_monitoring_config JSONB Beacon’s custom fraud rules
status VARCHAR(20) DEFAULT ‘active’  
created_at TIMESTAMPTZ  
updated_at TIMESTAMPTZ  

beacon_business_rules

Column Type Description
id UUID PK  
beacon_id UUID FK → beacons  
rule_type VARCHAR(50) See Section 3.1 rule types
rule_config JSONB Rule-specific parameters
applies_to VARCHAR(30) all, payment method, or product category
enforcement VARCHAR(20) hard_stop, warn (flag but allow with elevated margin)
status VARCHAR(20) DEFAULT ‘active’  
created_at TIMESTAMPTZ  
updated_at TIMESTAMPTZ  

clearing_audit_log

Column Type Description
id UUID PK  
clearing_transaction_id UUID FK → clearing_transactions  
event_type VARCHAR(50) risk_assessed, margin_computed, margin_held, settlement_instructed, settlement_confirmed, dispute_term_started, dispute_term_expired, dispute_payout, margin_released, cleared, declined_by_beacon, declined_by_risk, failed
actor VARCHAR(100) core, agent_id, system_timer, clearinghouse_adjudicator
previous_state JSONB Clearing state before this event
new_state JSONB Clearing state after this event
detail JSONB Event-specific payload
core_signature TEXT Ed25519 signature over canonical JSON of this record
created_at TIMESTAMPTZ Database-generated, not application-set

Constraints: Application role has INSERT only. No UPDATE trigger. No DELETE permission. Index on clearing_transaction_id + created_at for chronological reconstruction. Index on event_type for regulatory reporting queries.

5.2 Existing Table Modifications

6. Clearing Terms as Negotiation Surface

Clearing terms (dispute windows, payment timing, return policies) are part of the negotiation surface between Scout and Beacon. They are NOT unilateral declarations.

6.1 Payment Terms Schema

Beacons declare payment terms on offers:

{
  "payment_terms": {
    "accepted_methods": ["stablecoin_usdc", "card", "bank_transfer"],
    "timing": "on_fulfillment",
    "net_days": null,
    "dispute_window_days": 30,
    "return_policy": "full_refund_30_days",
    "currency": "USD",
    "terms_negotiable": true
  }
}

B2B with negotiated terms:

{
  "payment_terms": {
    "accepted_methods": ["bank_transfer"],
    "timing": "net_days",
    "net_days": 30,
    "dispute_window_days": 60,
    "return_policy": "per_agreement",
    "currency": "USD",
    "terms_negotiable": true
  }
}

6.2 Three Layers of Term Enforcement

Layer 1: Protocol minimums (Core-enforced, non-negotiable)

Core enforces market behavior rules that neither side can waive. These derive from MARKET_ECONOMICS.md — the protocol is a market institution, not a messaging layer.

Rule Minimum Rationale
Dispute window 7 days MARKET_ECONOMICS.md Section 4: adverse selection — markets without recourse drive out reliable sellers and buyers
Return policy transparency Must be declared Section 8: information architecture — both parties must know terms before commitment
Payment timing declaration Must be explicit Section 5: constraint satisfaction requires explicit bounds
Consent tier declaration Must match L5 DEC-040: consent elevation is protocol-enforced

Core rejects offers (or commits) that violate protocol minimums with a structured error indicating which rule was violated and what the minimum is.

Layer 2: Beacon business rules (Beacon-enforced, configurable)

Beacons declare hard stops — minimum buyer verification, blocked jurisdictions, etc. These are the seller’s acceptance criteria. See Section 3.1.

Layer 3: Scout acceptance criteria (Scout-enforced, configurable)

Scouts (or their principals via delegation scopes) declare their own acceptance criteria:

6.3 Rejection and Counter-Offer Protocol

Rejections are structured, not free-text. The protocol defines rejection reason codes:

Code Description
dispute_window_insufficient Requesting party wants a longer window
dispute_window_excessive Responding party won’t accept that long a window
return_policy_unacceptable Declared return policy doesn’t meet requirements
payment_timing_unacceptable Payment timing doesn’t work for this party
risk_margin_excessive Computed margin is too high (buyer pushback)
consent_tier_insufficient Per DEC-040
trust_level_insufficient Per business rules
jurisdiction_blocked Per sanctions/compliance rules
payment_method_unavailable Requested method not supported

Each rejection includes:

6.4 Offer Negotiation State Machine

Negotiation state lives on the offer object, not on the session. This is the correct boundary because negotiation is per-offer — a Scout may counter one offer’s terms while accepting another’s, and multiple offers can be in different negotiation states simultaneously within the same session.

stateDiagram-v2
    [*] --> proposed : Beacon submits offer with payment_terms
    proposed --> accepted : Scout accepts terms as-is
    proposed --> countered : Scout submits counter-proposal
    proposed --> rejected : Scout rejects terms (no counter)
    countered --> accepted : Beacon accepts Scout's counter-terms
    countered --> countered : Beacon submits adjusted counter (round N+1)
    countered --> rejected : Beacon rejects counter-proposal
    accepted --> [*] : Offer eligible for commitment
    rejected --> [*] : Offer closed

Offer negotiation states:

State Description
proposed Beacon has submitted offer with payment_terms. Awaiting Scout response.
countered One party has submitted a counter-proposal. Awaiting other party’s response. Tracks negotiation_round (1-indexed).
accepted Both parties agree on terms. Final agreed terms are frozen. Offer is eligible for commitment.
rejected One party rejected terms without counter. Offer is closed for negotiation.

Constraints:

Negotiation lifecycle:

1. Beacon submits offer with payment_terms → offer.status = proposed
2. Core validates against protocol minimums → REJECT if below floor
3. Scout reviews offer including terms:
   a. Accept → offer.status = accepted → eligible for commit
   b. Counter-propose → offer.status = countered (round 1)
   c. Reject with reason → offer.status = rejected
4. If countered → Beacon receives structured counter-proposal:
   a. Accept → offer.status = accepted → eligible for commit
   b. Counter (round N+1, max 3) → offer.status = countered
   c. Reject → offer.status = rejected
5. Commitment occurs on AGREED terms — final negotiated terms stored on transaction
6. Clearinghouse enforces the agreed terms (not original offer terms if negotiated)

Session state machine impact: The session state machine is unchanged. Sessions remain in offers_available while individual offers are being negotiated. The session transitions to committed when the Scout commits to an offer that is in accepted state. A commit against an offer not in accepted state is rejected.

7. Enforcement Model

The clearinghouse’s enforcement is grounded in mechanism design — structuring rules so that rational agents choosing their own best strategy produce outcomes optimal for the market as a whole.

7.1 Theoretical Foundations

Mechanism design (Myerson 1981, Maskin 1999). A mechanism is incentive-compatible if truthful behavior and rule compliance are each agent’s dominant strategy.

Mechanism How It Works Economic Property
Protocol minimums Core sets floor values for dispute windows, return policies, information disclosure Individually rational participation constraint — worst-case under protocol rules is better than best case in unregulated bilateral market
Risk-adjusted margins Agents who offer worse terms pay higher risk margins Incentive compatibility — cost of bad terms is internalized, not externalized to counterparty
Reputation-to-margin feedback Dispute outcomes degrade reputation → increase future margins → reduce competitiveness Dynamic incentive compatibility — shadow of the future (Axelrod 1984) given financial weight
Graduated sanctions First violation → margin increase; repeated → restrictions; persistent → suspension Graduated punishment (Ostrom 1990) — proportional response sustains cooperation

Adverse selection resistance (Akerlof 1970). Without enforcement:

  1. Beacons competing on price offer progressively worse terms
  2. Scouts cannot distinguish good-terms from bad-terms Beacons before committing
  3. Good-terms Beacons are undercut by bad-terms Beacons (lower risk exposure = lower prices)
  4. Good-terms Beacons exit → average quality declines → buyer trust declines → market failure

Protocol minimums break this at step 1. Risk margin mechanism ensures worse terms are more expensive above the floor.

Information architecture (MARKET_ECONOMICS.md Section 8). Core controls what each party sees:

Rule Enforcement Prevents
Terms declared on offer Core rejects offers with missing payment_terms Hidden terms discovered post-commitment (moral hazard)
Risk margin visible pre-commit Both parties see the margin Information asymmetry about transaction cost
Structured rejection reasons Protocol-defined codes Power asymmetry from opaque rejection
Agreed terms immutable post-commit Stored on transaction, signed, auditable Post-commitment term revision (hold-up problem)

7.2 Graduated Response Model

Core’s enforcement operates on a gradient, not a binary:

Level Condition Action Example
0: INFORM Terms within bounds but below market median Advisory flag to Scout “7-day dispute window is below market median of 21 days”
1: PRICE Terms create elevated risk Higher risk margin 7-day window → 2.5% margin vs. 30-day → 1.2% margin
2: RESTRICT Repeated disputes or problematic pattern Require higher verification, explicit consent, or escrow Beacon with >5% dispute rate → explicit consent required
3: BLOCK Protocol minimum violation or accumulated violations Hard rejection 0-day dispute window → rejected before publication
4: SUSPEND Persistent Level 2/3 violations, fraud indicators Clearing participation suspended pending review 3 months elevated dispute rate → suspended

Escalation between levels is deterministic (formula-driven, not discretionary). Thresholds published in operational documentation.

7.3 Why This Works for Agent Commerce

Per MARKET_ECONOMICS.md Section 12 (The Computable Market): agents are computationally rational within their delegated scope. They process risk margin as a cost input and adjust behavior accordingly. A human seller might ignore a 0.3% margin difference. An agent optimizing for revenue will detect that offering a 30-day dispute window reduces margin by 1.3% and adjust its offer terms to maximize net revenue. The enforcement mechanism doesn’t need to convince anyone — it needs to be priced correctly, and rational agents converge on the efficient outcome.

This is MARKET_ECONOMICS.md Design Principle 6: “Market design precedes algorithmic sophistication… Designing a better market makes good agent behaviour the rational strategy.”

8. Auditability and Forensic Durability

As an agency system handling funds on behalf of principals, every clearing operation must be independently auditable and forensically durable. This is not an observability concern — it is a legal and regulatory requirement.

8.1 Principles

  1. Every state change is an event. No clearing state transition without a corresponding audit record capturing who, what, when, why, and before/after state.
  2. Double-entry ledger. Every fund movement uses double-entry bookkeeping. Every debit has a corresponding credit. The reserve_ledger records both sides.
  3. Immutable records. Clearing audit records and ledger entries are append-only. No updates, no deletes. Corrections are reversal entries, not edits. Database-level enforcement: no UPDATE or DELETE permissions for application roles.
  4. Snapshot-at-decision. Every risk assessment stores a complete snapshot of all inputs (risk_inputs JSONB on clearing_transactions). If the reputation system later updates a Beacon’s score, the clearing record preserves what the score was when the margin was computed.
  5. External reference correlation. Every settlement instruction that touches an external system records the external reference, timestamp, and confirmation.
  6. Cryptographic binding. Clearing decisions are signed by Core’s Ed25519 key (same mechanism as intent chain and attestations). Modified records break the signature chain.

8.2 Forensic Reconstruction

Given a transaction_id, an auditor can reconstruct:

Dimension Source
Commercial agreement offers (product, price, terms, consent_requirements, payment_terms, signatures)
Commitment chain intent_chain_links (L1-L7, each signed, hash-chained)
Authority basis transactions.authority_attestation (delegation scope, consent tier)
Risk decision clearing_transactions.risk_inputs (bilateral risk snapshot, margin computation)
Beacon’s risk config at clearing time clearing_transactions.beacon_risk_config
Every fund movement reserve_ledger (double-entry, timestamped, referenced)
Every settlement instruction settlement_instructions (rail, external reference, status)
Every state transition clearing_audit_log (chronological, signed, immutable)
Dispute record (if any) disputes (evidence, resolution, protocol evidence chain)

All protocol data. No external system reconstruction required.

8.3 Retention

Financial records retained for the longer of: (a) regulatory minimum for applicable jurisdiction (typically 5-7 years), or (b) statute of limitations for commercial disputes. Clearing audit records and ledger entries are never purged by the application — retention policy enforced at the infrastructure level (database archival, not deletion).

9. Loss Waterfall

When a dispute is upheld and funds must be returned to the buyer:

1. Transaction risk margin (per-transaction reserve hold)
   ↓ If insufficient
2. Beacon risk reserve (accumulated from prior transactions)
   ↓ If insufficient
3. Pooled reserve (mutualized fund from all Beacon margins)
   ↓ If insufficient
4. Operator fund (AURA Labs capital — backstop of last resort)

This is a simplified version of the multi-layer default waterfalls used by DTCC, LCH, and CME. Expand when volume justifies additional layers (e.g., non-defaulter fund, insurance layer).

10. Real-World Clearinghouse Comparison

Dimension DTCC LCH CME Visa/MC ACH/SEPA AURA
Admission gates Net capital, FINRA EUR 50M+, regulatory FCM registration, $50M Bank charter, PCI-DSS Licensed PSP Principal verification, Ed25519 identity, behavioral history, business rules
Risk model VaR, CNS mark-to-market PAIRS (VaR 99.7%) SPAN (16 scenarios) Transaction velocity, fraud scoring Credit risk on originator Bilateral behavioral reputation + consent tier + category + amount
Margin structure Clearing Fund Deposit Initial + variation margin Performance bond Interchange + assessment Prefunding for high-risk Risk margin held for dispute term
Loss waterfall Defaulter → fund → DTCC capital Defaulter → fund → LCH → mutualized Defaulter → guaranty → CME → mutualized Issuer absorbs chargebacks DFI covers returns Transaction → Beacon reserve → pooled → operator
Settlement T+1 Daily + T+1/T+2 Daily + T+1 T+1 to T+2 (batch) Same-day to T+1 Event-driven (per offer terms)
Dispute model Corporate actions, fails Position disputes Delivery failures 81 chargeback codes NACHA return codes Protocol Section 11, evidence chain, clearinghouse adjudication
Audit SEC 17a-4 (3-6yr) EMIR trade repositories CFTC Large Trader PCI-DSS logs NACHA retention L1-L7 chain, double-entry ledger, signed records, 5-7yr

What we adopt: Loss waterfall structure (DTCC), bilateral-to-cleared transition (LCH), performance bond concept (CME), codified dispute taxonomy (Visa/MC), batch netting for microtransactions (ACH/SEPA).

What doesn’t apply: Physical securities settlement, interest rate scenario modeling, futures delivery logistics, issuer/acquirer bank charter requirements, multi-day batch as primary flow.

11. B2C vs. B2B vs. Agent-to-Agent Divergence

Dimension B2C / Consumer B2B / Enterprise Agent-to-Agent
Payment method Wallet (stablecoin, programmatic, card as legacy) Bank transfer, stablecoin, trade credit Programmatic wallet (stablecoin native)
Payment timing At fulfillment or at commit (digital goods) Per negotiated terms (Net 30/60, milestone) Atomic at commit (smart contract enforced)
Buyer pre-funding No — charged at settlement Optional — pre-funded for term trading Yes — wallets pre-funded at on-ramp
Dispute window Statutory + Beacon policy (14-30 days) Negotiated (may be 60-90 days) Protocol minimum + negotiated
Risk reserve term Short (14-30 days post-delivery) Longer (matching dispute window) Per terms; smart contract holds escrow
Identity requirements self_declared sufficient for small entity_verified/kyc_verified for credit Agent Ed25519 + principal verification
Clearing complexity Moderate: auth → settle → hold → release Complex: credit, invoicing, term tracking Simplest: atomic settle, programmatic escrow
Settlement model Real-time (wallet) or T+1 (legacy card) Event-driven or batched (optional netting) Real-time atomic (default)

12. What Doesn’t Translate from Financial Market Analogues

Concept AURA Adaptation Why
Variation margin Not needed Single-event transactions, not open positions
Netting Optional optimization, not default Requires high bilateral frequency; valuable for repeat B2B
Member qualification committees Principal trust levels entity_verified minimum for clearing; no human committees
Default waterfall (5+ layers) Simplified: 4 layers Expand when volume justifies
Bilateral clearing term negotiation Agents negotiate offer terms; clearing derives automatically No “let me check with my back office” — agents commit, clearinghouse clears
Market-making obligations Not applicable Beacons are sellers with inventory, not liquidity providers
Trading halts Session expiry + rate limiting Existing mechanisms suffice
T+2 batch settlement Event-driven per offer terms Agents expect real-time confirmation; batch netting optional for v2

13. Integration with Existing Systems

Existing System Integration Point
Transaction commit (transactions.js) After commit: create clearing_transaction, compute risk, initiate settlement per payment_terms
Offers (offers.js) Offers carry payment_terms and consent_requirements. Both feed the clearinghouse.
Dispute resolution (disputes.js) Clearinghouse adjudicator for clearing-enabled transactions; dispute payout from reserve; adjudicator.type: 'clearinghouse'
Consent elevation (DEC-040) Consent tier from L5/authority feeds margin calculator — higher ambiguity → higher margin
Intent chain (Phase E) Chain integrity is evidence for clearinghouse adjudication
Reputation system Risk engine reads reputation dimensions; clearing outcomes feed back into reputation
Beacon registration Beacons configure risk parameters at registration or via settings endpoint
Metrics New counters: clearing_risk_assessed_total, clearing_margin_held_total, clearing_settled_total, clearing_reserve_balance, clearing_dispute_payout_total, settlement_duration_seconds
Webhooks New events: clearing.risk_assessed, clearing.authorized, clearing.settled, clearing.cleared, clearing.dispute_payout

14. Protocol Specification Impact

The clearinghouse architecture requires changes across 16 sections of PROTOCOL_SPECIFICATION.md (v1.7). See DEC-043 for the full gap analysis. Total: 23 new subsections, 14 modifications.

14.1 Implementation Tranches

The 37 spec changes are sequenced into three independently testable tranches:

Tranche 1 — Minimum Viable Clearing Path

The structural foundation required before any clearing code. Each change in this tranche is a prerequisite for the clearing lifecycle.

Section Change Why First
4.5 (State Machine) 5 new states, 8 new transitions Clearing lifecycle cannot exist without these states
4.4 (Offer Object) payment_terms on offers Offers must carry terms before they can be negotiated or enforced
4.1 (Identifiers) New prefixes: clr_, rsv_, stl_, br_, rsk_ Tables need identifiers before data can be stored
10 (Transaction Commitment) Pre-commitment validation (10.2.5), settlement initiation (10.7) Commit is the entry point to clearing
12 (Error Handling) 9 new error codes Clearing failures need structured errors from day one

Testable milestone: A transaction can be committed, pass through risk assessment, be authorized, settle, and reach cleared state. Dispute term tracking works. Error codes returned for business rule violations and settlement failures.

Tranche 2 — Dispute Integration and Identity Extensions

Connects clearing to dispute resolution and extends identity/authority for clearing participation.

Section Change Why Second
11.8-11.10 (Dispute Resolution) Clearinghouse adjudication, graduated escalation, protocol minimums Disputes draw from reserves — requires working reserve system from Tranche 1
3.1 (Principal Registration) Risk profiles (3.1.4), business rules (3.1.5) Business rules gate requires identity extensions
3.2 (Agent Registration) Settlement wallet, enforcement status (3.2.8) Settlement requires wallet addresses; enforcement requires status tracking
3.3 (Authority & Consent) Clearinghouse authority verification (3.3.6) Consent tier → margin mapping requires authority extensions
13 (Security) Settlement security (13.6), business rule security (13.7) Security model must cover the new clearing surface

Testable milestone: Disputes trigger reserve draws. Business rules gate rejects non-compliant transactions. Graduated enforcement tiers apply. Settlement wallet verification works. Beacon risk configuration is per-payment-method.

Tranche 3 — Negotiation, Ranking, and Completeness

Advanced features and documentation completeness. Can follow initial clearing implementation.

Section Change Why Third
2 (Design Principles) 4 new principles (2.3a, 2.4a, 2.5a, 2.6a) Codifies what Tranches 1-2 already implement
5, 7, 8 (Scout/Beacon flows) Settlement preferences, scout context, offer signature updates, CCP acknowledgment Enriches flows that already work at basic level
6 (Interpretation) Clearinghouse interpretation hints (6.7) Optimization — pre-filtering based on clearinghouse compatibility
9 (Offer Ranking) Risk adjustment in CWR, business rule filtering Ranking refinement — offers already work without it
14 (API Reference) Phase 7 reserved endpoints Documents what Tranches 1-2 implement
15 (Implementation Notes) Clearinghouse checklist (15.4) Guidance for implementers
16 (Future Extensions) Phase 7 formalization (16.0), term negotiation (16.1a) Formalizes the negotiation protocol from Section 6.4
A, D (Appendices) JSON schemas, telemetry events Reference material for what is already built

Testable milestone: Full offer negotiation with counter-proposals. Risk-adjusted ranking. All protocol spec sections complete and internally consistent. Appendix schemas validate against implementation.

15. Open Questions (Carried from ROADMAP.md)

Version History

Date Change
2026-04-09 v1.0 Initial architecture document. Covers 8 clearinghouse sub-components, 4 transaction lifecycle flows, data model (7 tables), clearing terms negotiation, enforcement model, auditability, loss waterfall, CCP comparison, protocol specification gap analysis. Driven by DEC-034, DEC-043.
2026-04-09 v1.1 Review feedback: (1) Custody model rewritten — multi-custody is launch requirement, custody routing follows payment method at clearing time. (2) Reserve ledger concurrency strategy documented — SELECT FOR UPDATE on clearing_account row. (3) B2B-specific risk inputs added to risk engine (outstanding exposure, payment timeliness, credit concentration). (4) Offer negotiation sub-state machine defined (proposed → countered → accepted/rejected, max 3 rounds). (5) Protocol spec changes sequenced into 3 independently testable tranches.

Document History

Version Date Changes
1.1 2026-04-14 Added version header, protocol reference updated to v2.2. Updated verification_level references to trust_level (DEC-049).
1.0 2026-04-09 Initial clearinghouse architecture — CCP model, risk engine, reserve management, settlement orchestration, enforcement. DEC-043.