oracle — a TDX-attested price oracle

audience: ai

This example walks a TDX-attested price oracle: one standalone organism that ships a family of price-tick streams, one stream per token pair, with the whole trust model anchored on a declared TDX Measurements set. Consumers that trust the oracle’s image — that is, that admit its Measurements in their TicketValidator — inherit the oracle’s prices by construction. No reputation layer is required for the minimal shape to work; the attestation is the admission criterion.

The oracle lives in its own small coalition, oracle-γ, which references the oracle organism and (optionally, from chapter 7) a Chronicle for audit of Measurements rotations. The chapter walks mirror the web3 and web2 examples rung for rung, re-interpreted for a data-publisher: reads become source reads, wrapping wraps exchange feeds into the enclave, inference becomes in-enclave aggregation, sealed submission becomes continuous stream publication.

Unlike the other two examples, the oracle is a pure standalone organism — it lives directly on the universe and any coalition can reference it via OrganismRef. oracle-γ is a packaging convenience for the operator’s own retirement chain and Chronicle; no consumer has to reference oracle-γ to consume the oracle.

What is assumed

• TDX is in the composition. The oracle only makes sense when consumers can verify the image it runs. Non-TDX operation is technically possible (a developer’s local build exposing streams) but outside the trust model this example demonstrates.
• Readers understand Part I. The four agent shapes, the four emergent-coordination patterns (attestation fabric is the load-bearing one here), the TDX/non-TDX split, and the stigmergic-collection pattern for per-key streams are assumed. Part II does not re-explain them.
• No implementation crates yet. Code blocks are rust,ignore specification shapes matching the book’s crate plan (coalition, mosaik::tee::tdx, a hypothetical oracle-feed helper crate).

The oracle’s shape

• Coalition. oracle-γ — the oracle operator’s own CoalitionConfig. References one lattice (none, in the minimal version) and one standalone organism (the oracle itself). Ships no basic services in the minimal version; Chronicle is optional from sustainability.
• Primary member. One shape-2 standalone organism — the oracle, wrapped as a mosaik organism whose public surface is a family of Stream<PriceTick> keyed by token pair. Its Config folds the source catalog hash, the aggregation-policy parameters, the supported token-pair set, the publication cadence, and — because TDX is always in the composition — the image post-hash.
• Binding direction. The oracle is what consumers bind to, not what binds to anyone else (except its upstream price sources, which it reads through non-mosaik feeds wrapped at wrapping). A coalition that wants oracle prices references the oracle via OrganismRef and admits its Measurements in its own TicketValidator.

What runs where

TDX on the oracle itself is not optional. A non-TDX build cannot produce the self-quote consumers pin against; admitting a non-TDX price feed collapses the trust model.

Chapters

1. Setup and shape — dependencies, CoalitionConfig for oracle-γ, the oracle’s OrganismConfig and declared Measurements.
2. Binding consumers — how a consumer coalition references the oracle via OrganismRef, composes its TicketValidator, and performs its first stream subscription.
3. Reading price sources — what the oracle subscribes to inside its enclave: CEX spot APIs, on-chain pool reads, staleness accounting.
4. Wrapping source feeds — lifting non-mosaik upstreams into the enclave: pinned TLS, archive or light-client reads, the source-availability state machine.
5. Aggregation in the enclave — per-pair tick derivation: median, VWAP, outlier rejection, confidence, the source-set digest.
6. Stream publication — one Stream<PriceTick> per token pair, StreamId derivation, commit cadence, the per-bond attestation surface.
7. Rotation, retirement, successor chain — Measurements rotation, multi-operator fleets, retirement markers, operator-side exit.

Unlike web3, there is no market-maker variant; unlike web2, there is no provisioning side. The oracle has one shape: publish, continuously, under a pinned image.

Register and non-goals

• Register. audience: ai — research-monograph, pattern-forward, code-forward where a shape is load-bearing. Density matches web3 and web2.
• Non-goal. This is not a guide to building a production price oracle. Feed selection, upstream contracts with exchanges, commercial terms, regulatory posture, and settlement accounting are out of scope. Where the substrate touches those questions, the chapter names the boundary and stops.
• Non-goal. The example does not compare the mosaik-native composition to existing oracle networks (Chainlink, Pyth, Chronicle, UMA). Those systems solve adjacent problems under different trust anchors; the relevant delta here is that the oracle’s guarantees reduce to one declared Measurements set and the consumers’ willingness to admit it.
• Non-goal. The example does not specify the Compute basic service. The oracle runs its own TDX process; it does not use the coalition’s Compute module to schedule aggregation. An operator who wanted to schedule aggregation on Compute could do so, but that is a different example.

Cross-references

• Part I — AI overview
• Part I — emergent coordination — attestation fabrics
• Part I — sustainability
• Part II — web3 overview
• Part II — web2 overview
• Part III — contributors — composite organisms