# Multi-Oracle Consensus Protocol for Market-State Verification --- **Version**: 1.0.1 (errata correction, 2026-04-22) **Status**: Published Standard **License**: MIT **Editor**: Headless Oracle (headlessoracle.com) **Canonical URL**: https://headlessoracle.com/docs/specifications/multi-oracle-consensus-v1 **Machine-Readable**: https://headlessoracle.com/v1/verification/multi-oracle-guide **Changelog**: v1.0.1 removes references in Sections 3 and 10 to a regulatory framework name that did not correspond to a specific published document. Replaced with citations to CFTC Staff Letter 25-39 (December 2025) and the SEC Crypto Task Force Project Blueprint on Tokenized Collateral (November 2025), both of which are government-published. Section 10 ESMA/NIST/MAS references removed pending independent verification. --- ## Abstract This specification defines how an autonomous agent SHOULD query multiple independent market-state oracles and reach consensus before executing a financial transaction. It establishes a minimum-oracle-count threshold and a fail-closed consensus algorithm consistent with the architectural direction in emerging regulatory guidance on tokenized collateral (CFTC Staff Letter 25-39, December 2025; SEC Crypto Task Force Project Blueprint on Tokenized Collateral, November 2025). This is a verification standard for *market state* — whether an exchange is open, closed, halted, in pre-market, after-hours, on a scheduled break, or unknown — not for *price feeds*. Price-oracle consensus is out of scope. ## 1. Scope In scope: - Verifying whether one or more exchanges are in a tradeable state at a given instant. - Reaching agreement across independent oracle providers on that state. - Defining the minimum cryptographic and structural requirements an oracle response MUST meet to participate in consensus. - Defining the agent-side decision rules that turn N oracle responses into a single execute / do-not-execute outcome. Out of scope: price discovery, settlement, custody, identity of the oracle operator (covered separately by APTS and MPAS). ## 2. Terminology The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119. **Signed Market-State Attestation (SMA)** — A cryptographically signed statement, issued by an oracle, asserting the state of a single exchange at a single point in time. **Oracle feed** — An independent oracle endpoint that issues SMAs. Two feeds are independent if they are operated by different entities, signed with different keys, and do not share an upstream data source or signing infrastructure. **Consensus threshold** — The minimum number of oracle feeds whose valid SMAs must agree on the same market state for the agent to proceed. Defined as `floor(N/2) + 1` where N is the number of valid responses. **Fail-closed default** — The behavior an agent MUST exhibit when consensus cannot be established: treat the market as CLOSED and do not execute the trade. **UNKNOWN** — A distinct market-state value that an oracle MUST emit when it cannot determine the true state. UNKNOWN is treated as CLOSED for execution purposes but MUST be preserved as UNKNOWN in audit logs. ## 3. Minimum Oracle Count An agent MUST query at least three independent oracle feeds before executing any trade where venue-state verification is load-bearing for capital safety. Fewer than three valid responses MUST result in a fail-closed outcome. This threshold reflects standard Byzantine-fault-tolerance practice (tolerance of one faulty feed in three) and is consistent with the architectural direction in the SEC Crypto Task Force's Project Blueprint on Tokenized Collateral (November 2025). ## 4. Consensus Algorithm The agent MUST implement the following algorithm: 1. Query all configured oracle feeds in parallel with a uniform timeout (RECOMMENDED: 2000 ms). 2. For each response, perform the verification flow defined in section 6. 3. Discard any response that fails verification or whose `expires_at` has passed. 4. Let `V` be the set of remaining valid SMAs. If `|V| < 3`, the agent MUST NOT execute the trade. 5. Group `V` by `status`. Let `M` be the largest group. 6. If `|M| >= floor(|V|/2) + 1` AND every member of `M` has `status = "open"`, the agent MAY proceed. 7. In all other cases — including a tied vote, a majority for any non-open status, or unanimous disagreement — the agent MUST NOT execute. The agent SHOULD log the disagreement for human review. The algorithm is named `majority_with_fail_closed`. ## 5. Attestation Format Each oracle response MUST contain at least: | Field | Type | Description | |------------------|---------|-----------------------------------------------------------------------------------| | `exchange` | string | ISO 10383 Market Identifier Code (MIC), e.g. `XNYS`. | | `status` | enum | One of: `open`, `closed`, `pre_market`, `after_hours`, `break`, `halted`, `unknown`. | | `timestamp` | string | ISO 8601 UTC instant the attestation was issued. | | `expires_at` | string | ISO 8601 UTC instant after which the attestation MUST NOT be acted on. | | `signature` | string | Base64-encoded Ed25519 signature (or equivalent). | | `public_key_url` | string | HTTPS URL where the oracle's signing key can be retrieved. | | `oracle_id` | string | Globally unique identifier for the oracle provider. | The interval `expires_at - timestamp` MUST NOT exceed 60 seconds. The `status` enum is closed: an oracle MUST NOT emit any value outside this set. ## 6. Verification Flow For every oracle response, the agent MUST execute the following steps in order. Failure at any step MUST cause the response to be discarded. 1. **Discover** the oracle endpoint via MCP, `/.well-known/agent.json`, `/.well-known/oracle-keys.json`, a registry, or hardcoded configuration. 2. **Fetch** the response under the timeout from section 4. 3. **Parse** the response and confirm every field in section 5 is present and well-formed. 4. **Retrieve** the public key from `public_key_url` (cache MAY be used; TTL no longer than 24 hours). 5. **Verify** the signature against the canonical payload as defined by the oracle's published signing specification. 6. **Check freshness** — `expires_at` MUST be in the future relative to the agent's current monotonic clock. 7. **Admit** the response to the consensus pool only if every preceding step succeeded. ## 7. Error Handling | Condition | Required behavior | |------------------------------------------|----------------------------------------------------------------| | Network timeout | Treat as missing; do not include in `V`. | | Invalid signature | Discard. Log `oracle_id`, `signature`, reason. | | Expired `expires_at` | Discard. | | Schema violation | Discard. | | Disagreement (no clear majority) | Use majority if it favors `open`; otherwise fail-closed. | | Fewer than 3 valid responses | Do not trade. Hard floor. | | Public key fetch failure | Discard. Optionally retry once with backoff. | | Oracle returns `unknown` | Count as a vote for `unknown` (not `open`). | Errors MUST NOT be silently swallowed. ## 8. Cryptographic Requirements The default signature algorithm is Ed25519. Alternates MUST be declared at `public_key_url`, MUST be supported by the agent's verifier, and MUST provide at least 128-bit security. ECDSA-secp256k1 and Ed25519 are RECOMMENDED. RSA-PSS with at least 2048-bit keys is permitted. SHA-1 and 1024-bit RSA are forbidden. ## 9. Reference Implementation Headless Oracle is the first compliant implementation. | Property | Value | |-------------------------|----------------------------------------------------| | `oracle_id` | `headlessoracle.com` | | Endpoint (REST) | `https://headlessoracle.com/v5/status` | | Endpoint (MCP) | `https://headlessoracle.com/mcp` | | `public_key_url` | `https://headlessoracle.com/v5/keys` | | Signature algorithm | Ed25519 | | Exchanges | 28 global venues | | Receipt TTL | 60 seconds | | Fail-closed | Yes — `unknown` is always treated as `closed` | A second and third independent implementation are required to satisfy the minimum oracle count in production. ## 10. Regulatory Alignment This specification is architecturally consistent with emerging regulatory direction on tokenized collateral and algorithmic execution: - **CFTC Staff Letter 25-39** (December 2025) — technology-neutral guidance on tokenized collateral; final rulemaking expected August 2026. - **SEC Crypto Task Force Project Blueprint on Tokenized Collateral** (November 2025) — discusses multiple independent oracles and cryptographic attestation as architectural building blocks. Where this specification uses RFC 2119 MUST/SHOULD language, the normative force derives from the specification itself, not from any external regulatory document. Operators MUST evaluate their own regulatory obligations independently. ## 11. Versioning This is version 1.0.1 (errata correction from v1.0.0). Backwards-incompatible changes will be published under a new major version at a new URL. Comments and errata: https://github.com/LembaGang/headless-oracle-v5/issues. ## 12. License This specification is published under the MIT License.