LON Oracle Zone - Architecture Draft Specification

1

LON Oracle Zone - Architecture Draft Specification

Summary

This post drafts an alternative architecture for the Logos Oracle Network (LON): a dedicated Oracle Zone that produces an attested, consensus-backed price feed without requiring a separate signature committee, or off-chain aggregation trust.

The key insight: a Logos zone already verifies and price inscriptions through its validator set. If oracle nodes write signed price data as inscriptions, the zone’s own execution path verifies signatures, filters outliers, and computes the median as part of normal block processing. The resulting price is as secure as the zone’s consensus.

This approach is inspired by Pyth Network’s architecture, which operates its own dedicated chain (Pythnet) for collecting and aggregating price data from publishers. However, where Pyth relies on a bridge-like mechanism (Wormhole) to deliver price data from Pythnet to target chains, the Logos ecosystem enables cross-zone data transfer natively through PACT (Provably Atomic Cross-zone Transaction). This eliminates a separate bridge trust assumption and allows the Oracle Zone’s attested price to be consumed by the Logos Execution Zone (LEZ) and other possible zones through the same trustless mechanism the protocol already provides.

This spec is derived directly from two existing zone implementations: the SQLite Sovereign Zone demo and the Logos Execution Zone (LEZ).

Background: How Logos Zones Work

A Logos zone is built from three roles on top of the Bedrock:

Bedrock (Logos chain) orders and finalizes arbitrary data blobs called inscriptions. It does not interpret their contents. It only guarantees that a given inscription was written, by a given key, in a given order.

Sequencer writes inscriptions to Bedrock. It collects data, packages it, and publishes it to a channel.

Indexer reads inscriptions from Bedrock and reconstructs the zone’s state. It is the zone’s interpretation layer: it takes the ordered blob stream and applies the zone’s own logic to produce state.

The two reference zones differ only in what the indexer does with each inscription:

Zone Inscription payload Indexer logic Resulting state Reference
SQLite Sovereign Zone SQL statement Replay SQL SQLite database logos-sql-zone
LEZ Serialized TXs Deserialize, apply transactions RocksDB account state indexer/core
LON Oracle Zone (proposed) Signed price record Verify sig, filter, compute median Attested price state - (yet)

In Oracle zone, the indexer logic runs across the zone’s validator set. Still, this design deliberately leaves the aggregation model open. We can have two options:

On-chain aggregation (preferred if indexer throughput permits enough big oracle). The indexer logic itself computes the median from all inscriptions in the round. With a sufficiently large oracle node pool, outlier filtering makes manipulation impractical without capturing a majority of contributors. Security scales with oracle count, not validator count.

Off-chain aggregation (fallback). If indexer throughput is a constraint, aggregation moves off-chain. This requires a Byzantine Fault Tolerant (BFT) leaderless protocol among oracle nodes to agree on a price before writing a single inscription to Bedrock. The zone then simply records the agreed result rather than computing it.

The primary goal of the Oracle Zone design is not to mandate one of these paths, but to separate the oracle function from LEZ so that price data feeding does not create load on the LEZ execution layer. Both aggregation paths are compatible with this goal.

Architecture

Flow

Oracle Node 1 ─┐
Oracle Node 2 ─┼─→ signed price inscription ─→ Bedrock (orders + finalizes)
Oracle Node .  ┼
Oracle Node N ─┘                                      │
                                                      ▼
                                       Oracle Zone indexer logic
                                       (runs across validator set)
                                       1. sig verification 
                                       2. check writer in permissioned/staked set
                                       3. filter outliers by deviation bound
                                       4. if quorum: compute median
                                       5. write attested_price to zone state
                                                      │
                                                      ▼
                                       Attested price in Oracle Zone
                                       public state (consensus-backed)
                                                      │
                                                      ▼
                                       [LEZ consumption - separate process,
                                        out of scope of this post]

Step by step

  1. Signed price inscription. Each oracle node fetches prices off-chain from multiple sources, computes a local median (if offchain design), signs the record (pair, price, timestamp), and publishes it as an inscription to Bedrock. This is the sequencer role - each node is its own sequencer writing to its own channel.

  2. Ordering. Bedrock orders and finalizes the inscriptions. No interpretation happens here.

  3. Verification and aggregation. The Oracle Zone indexer logic processes each finalized inscription:

    • Verify the signature (see signature benchmark).
    • Confirm the writer is in the permissioned set, or holds sufficient stake (Sybil resistance).
    • Discard records outside the deviation bound relative to the running median.
    • Once a quorum of valid submissions exists for a pair, compute the median.
    • Write the result as attested_price to the zone’s public state.

    Because this runs across the validator set under BFT consensus, the attested price cannot be manipulated by a minority of validators.

  4. Consumption. The attested price lives in the Oracle Zone’s public state. How LEZ programs read it (direct cross-zone read vs. PACT) is deliberately left out of scope here and tracked as an open question.

Why This Removes the Signature Committee Problem

In the LEZ-native iteration model, a key open problem was how a separate signing committee attests to the price. The Oracle Zone design removes this entirely:

  • The validators already verify each submission’s signature during block processing.
  • There is no separate “signing” step layered on top of “voting” - they are the same step.
  • Idle validator detection is unnecessary: validators that do not participate in consensus simply do not contribute to the agreed state, which is the normal liveness mechanism of the chain.

The attested price inherits the security of the zone’s consensus. The only remaining trust assumption is the honesty of the oracle nodes’ data (a node can sign a valid but wrong price), which is addressed by economics, not cryptography.

Security Model

Layer Threat Mitigation
Inscription authenticity Forged price from a non-oracle Ed25519/Schnorr signature; only known keys accepted
Sybil Attacker spins up many oracle nodes Permissioned set initially; minimum stake to join later
Data quality Oracle signs a valid but wrong price Outlier filtering + median across N nodes; stake/slash
Targeted attack Attacker bribes/DDoSes the writers of a round Large pool + randomized committee selection per round
Aggregation integrity Malicious validator computes wrong median BFT consensus across validator set; minority cannot alter result

Two mechanisms compound to make data manipulation impractical:

  • Many writers. Manipulating the median requires controlling more than half of the contributing nodes; cost scales linearly with pool size, and outlier filtering blunts single-node influence.
  • Randomized committee per round. If a random subset writes each round, the attacker cannot know in advance which nodes to target. The attack window collapses to a single round (~30s), within which capturing a majority of an unknown subset is impractical. This is the Algorand sortition model applied to oracles.

Layers to Build

The following components must be implemented. Each maps to a known reference in the SQLite zone or LEZ codebase.

1. Oracle Node (Sequencer role) - new

Off-chain agent run by each oracle operator.

  • Fetch prices from ≥2 sources, compute local median.
  • Sign the record (Schnorr secp256k1).
  • Publish as inscription via the zone Software Development Kit (SDK) sequencer interface.

Reference: SQLite zone sequencer.rs (publish_message / batch flow), LEZ block_publisher.

2. Oracle Zone Indexer Logic (Indexer role) - new, core of the work

The interpretation layer. Replaces SQLite-replay (SQL zone) and block-deserialization (LEZ) with oracle aggregation.

  • Subscribe to the channel via ZoneIndexer (next_messages / subscribe_parse_block_stream).
  • For each finalized inscription: deserialize the price record.
  • Verify signature.
  • Check writer membership (permissioned set or stake lookup).
  • Filter outliers against running median (deviation bound - fixed initially, adaptive later).
  • On quorum, compute median deterministically (block-indexed window, not wall-clock - see note below).
  • Write attested_price to zone state.

Reference: LEZ indexer/core/src/lib.rs (subscribe_parse_block_stream), SQLite zone indexer.rs (replay loop) and state.rs (ZoneState trait).

3. Price Record Format - new, small

Borsh-serializable struct: { pair, price, timestamp, writer_pubkey, signature }. Shared between node and indexer.

Reference: SQLite zone message.rs (Msg / payload encoding).

4. Zone State Schema - new, small

State layout holding per-pair attested prices and the in-progress submission set for the current round.

Reference: SQLite zone state.rs InMemoryZoneState (in production, backed by a persistent store like LEZ’s RocksDB).

5. Membership / Stake Module - new, deferred to permissionless phase

Determines who may write. Permissioned whitelist for the first version; stake-based admission for the permissionless phase.

6. Randomness Module - deferred

Committee selection per round. Tracked separately; uses Bedrock entropy contribution or commit-reveal over gossip. Not required for the permissioned first version.

7. LEZ Consumption Path - out of scope, open question

How a LEZ program reads the Oracle Zone’s attested price. Two candidates: direct cross-zone read, or PACT. Needs clarification from the Logos core team.

Determinism Note

Aggregation must be deterministic so every validator reaches the same attested price. The median window must be defined by inscription order or block height, not wall-clock time. A query like “median of the last 30 seconds” produces different results on each validator because each sees a different now(). Use “median of submissions in the last N blocks” or “since block height H” instead.

Open Questions

  1. LEZ consumption. Can a LEZ program read another zone’s state directly, or is PACT required? What is the PACT end-to-end latency?
  2. Oracle Zone validator set. Does the zone use its own validator set, or inherit Logos main-chain security (shared / opt-in)? A small independent set is weaker than the claim “as secure as the chain.”
  3. Finality latency. How long until an inscription is finalized (below Last Irreversible Block (LIB))? What is the reorg tolerance for attested_price?
  4. Stake / slash definition. How is “wrong price” proven and slashed? Defined at zone level or Logos level?
  5. Quorum and deviation parameters. Minimum submissions per round; fixed vs. adaptive deviation bound.

Next Steps

  • Validate the indexer-logic approach against ZoneIndexer SDK capabilities (does it expose what we need for per-inscription processing?).
  • Prototype the price record format and a minimal aggregation indexer over a mock channel.
  • Resolve the LEZ consumption question with the core team before committing to a delivery path.