This post presents the initial design requirements for Logos Oracle Network.
Also this post is related to latest IFT research call post.
The oracles are entities that provide offchain information to the blockchain. In particular, Logos oracle network brings the data to the Logos Execution Zone (LEZ) environment. Oracle mechanism secured the financial operation in blockchain, such as swaps in DEXs, prediction markets and stable coin creation. Finally, oracle problem solution requires distributed writing to the chain by multiple nodes as well as a consensus among these nodes to achieve decentralization.
For the initial oracle requirements of LEZ is considered with the integration of the existing mechanism, see the request for proposal (FRP). LON is next level mechanism that is stand alone oracle mechanism for better decentralization and consists of following requirements and components as follows:
- Requirements
- Decentralization
- Permissionless
- Liveness
- Data accuracy
- Types and Capabilities: Pull, Push and Commit-Reveal
- Components
- Dispute solving
- Aggregation
- Randomness
- Voting-based consensus
Note that, some of the components such as voting based consensus may be excluded for the final version.
Decentralization
LON aims decentralization at the protocol level, which means no individual (or small group) can write the data itself. This can be achieved in two ways according to aggregation type; First, onchain aggregator, the individual nodes just fetch the data and send to the contract, the contract verifies the signature is valid and deviation is acceptable, then outputs the median. Secondly, offchain aggregation by multi, threshold or aggregated signatures that each node may participate independently in a signing round with equal chance see the randomness section. The random selection of the sign committee provides the potential colluded nodes from coming together for manipulation.
Permissionless
LON aims to be permissionless, where any node can join the signing pool without approval, unlike many existing oracle mechanisms that require legal agreement for oracle nodes for data accuracy and liveness promises. Instead of legal agreement, LON may benefits stake based economic guarantee which also requires fair and secure dispute mechanism. Realistically, the initial iterations will be permissioned for operational safety such as collusion and sybil attacks, iterating toward full permissionless participation. We make sure the oracle manipulation is expensive enough in this setting.
Liveness
With two previous features, liveness may be achieved in incentivization with a good reward or a slash from the stake, maybe both. However, we had a good incentivization mechanism still, we can use similar approaches from de-MLS track so we handled some similar possible problems, such as if there is no proposal creator, re-election mechanisms and deadlock recovery. Maybe also design backup network and enable it when the oracle liveness health (potential deadlock) is getting low.
Data Accuracy
Oracle’s manipulation of prices is money. So we must assume that a highly incentivized the oracle node may conduct malicious activity, or collusion with others. The possible methods that we can use for data accuracy guarantee.
- Voting consensus (BFT based): up to n/3 malicious nodes cannot corrupt the result as additional economic security, if there is BFT based offchain consensus integration.
- Multi-source per node: each node fetches from at least 2 whitelisted sources and computes a local median. Single-source manipulation does not propagate. Since we cannot enforce this, we need to rely on a reward and slash that makes the each oracle calculate the correct price by following the protocol.
- Median of medians: the network-level result is the median of all nodes’ local medians, based on aggregation type offchain or onchain.
- Setting deviation bound existing oracle mechanism use 0.1% (or similar) deviation bound, if the attested price is more than this, it is needs to be dropped again based on aggregation type offchain or onchain.
- Good randomness the network needs to make hard to colluded oracles come together via unpredictable randomness.
There are also two type of deviation, fixed or adaptive:
Fixed deviation (e.g., 0.1%):
- Simple, predictable, easy to audit
- Fails during genuine high-volatility periods - a real 5% price move gets rejected as manipulation
- Attacker can stay just under threshold and slowly drift the price (“griefing by inches”)
Adaptive deviation (volatility-based):
- Widens during high volatility, tightens during stable periods
- Avoids false positives on genuine price moves
- Introduces new attack surface - manipulate the volatility measure itself to widen the threshold, then manipulate the price within the wider band
No clean solution. Fixed is safer to reason about, adaptive is more accurate. Most existing systems use fixed.
Type Capability - Pull, Push, or Commit
There are many ways that we need oracles with different requirements, such as:
- prediction market
- DeFi lending markets
- money markets
- perpetual/derivatives DEXs
- stablecoin issuers
- tokenized RWAs
Prediction markets — latency is secondary. DeFi lending markets need manipulation-resistant, fresh prices with heartbeat and deviation triggers; Liquid (re)staking tokens (LSD/LRT) peg deviations require the oracle to halt rather than propagate a divergent value. Money markets are most exposed to stablecoin depegging — a missed depeg reported as $1.00 causes instant insolvency. Perpetual DEXs require sub-second freshness and front-running protection. Stablecoin issuers need tight multi-source peg monitoring with high divergence thresholds. Tokenized RWAs are the outlier — Net Asset Value (NAV) comes from a single trusted custodian, making decentralized consensus irrelevant. Note that, priority in Logos looks at stablecoin issuers and DEX first.
Therefore, LON may be divided into three types.
PULL: LON finalizes a price round off-chain. The signed package is cached in the Logos Delivery gossipsub layer. Consumers fetch it on demand and submit it to LEZ within their own transaction.
pros:
- gas cost on user, easy to handle
- efficient for long tail assets
cons:
- reading the data is not free, only used particular calldata of TX
- sensitive to liveness
PUSH: A pusher service periodically fetches the latest finalized package and writes it to LEZ. Trigger: heartbeat interval (e.g., 30s) OR price deviation threshold (e.g., >0.1%). Push = Pull + periodic trigger. Pull is the primitive; push is an operational layer on top. Converting pull to push is trivial; the reverse is not.
pros:
- write one, read timeless for free
- easy to use, just bring price then use it
- fresh as a heartbeat
cons:
- if data is not use, continue to write so gas costy
- who handles the gas cost, usually an oracle mechanism get agreement with chains and users can use them free.
- not efficient for long tail assets
Commit-based: The voting result is committed on-chain before the signed price is accepted. The OracleContract verifies both the voting aggregate and the signing aggregate. A malicious signed value cannot finalize without prior on-chain voting confirmation — this structurally prevents the “profitable attack after slash” problem where the exploit gain exceeds slash penalty. Suitable for perp DEXs which not in scope currently.
Dispute Solving
Dispute resolution handles what happens when a written data in chain violates the real price due to an attack or bug.
Existing systems: Chainlink handles misbehavior through off-chain reputation and operator removal — no on-chain dispute. RedStone has no dispute mechanism (yet), only economic deterrence. UMA’s optimistic oracle is the closest general-purpose approach but resolution takes hours. None provides fast trustless on-chain dispute for continuous price feeds.
Decentralized approach: Signing committee nodes stake collateral. A value that contradicts network consensus triggers an on-chain slash method without a trusted party or legal agreement. The profitable attack problem remains: if a malicious value is exploited before slash arrives, the attacker profits even after losing stake.
Iteration path: Start with a trusted permissioned multisig for dispute execution. Progressively replace with on-chain slash contracts, open challenge submission to any node, then introduce the commit-based model. Full permissionless dispute resolution is the target state.
Aggregation
Aggregation is computing a median result from the many different median prices. The median result was computed in two ways and its cons and pros.
On-chain aggregation: each node writes its price directly to a contract; the contract discards outliers (deviation bound) and computes the median. Simple and transparent. Gas cost scales linearly with n (especially in PUSH types - unless we use a non-aggretable signature), signature verification and checks.
Off-chain aggregation Data (price) aggregation happens off-chain via gossipsub before signing. Only the final result (price + aggregate signatures) is submitted on-chain. Gas cost is similar to on-chain one (only signature verification). Value is finalized before submission. The issue here, the oracle nodes needs to get aligned on a single unique data to sign so off-chain aggregation requires one layer. In existing mechanisms, sometimes this is handled by a leader (close to a trusted one).
There is no big difference in terms of the signature verification number. This number only changes when there is trust issue, for trustless oracle, we need to increase the number of signature verification onchain.
Both way, we face the signature verification in LEZ. The signature scheme is open right now. BLS aggregate is the natural fit (constant on-chain verification cost, n-independent) but is not quantum-secure and pairing computation is expensive in RISC0 (~2M cycles per verification). This cost per heartbeat may be prohibitive. This is the central unresolved technical question for LON. See the LEZ signature benchmark here.
Randomness
Randomness is a key requirement that makes it hard to get into the same group of malicious oracle nodes for an attack. The sign committee needs to be chosen based on this randomness. A good randomness needs to satisfy these features:
- unpredictability (no party can predict output before the round seed is fixed)
- unbiasedness (no coalition can skew the output)
- verifiability (anyone can verify correctness after the fact)
- liveness (generation completes within the round window)
There are some examples in literature for that, VRF (plain+commit/reveal), randao but none of them is perfect, all have cons and pros.
Voting based consensus
So far, we have only mentioned the sign committee which regardless the aggregator, and oracle type (PULL/PUSH). But now, we talk about BFT based consensus, it’s necessity, and how we can use it?
The original BFT based binary voting starts with a proposal dissemination. Then everyone put their votes as YES or NO then as a result, everyone in the network gets the same result.
Possible usage areas:
1. Making the leader transparent in off-chain aggregator
- one leader starts a proposal and others vote on it
- if the result is YES, sign committee signs the data on the proposal
- as open questions, what happens if there is NO, also multiple proposal
- cons, another stage brings low latency
- pros, the leader will be trustless
2. Modified off-chain aggregator
- Each voting phase, the voters add their median and send the new aggregated value
- When consensus achieves finality, everyone outputs the same data
3. Another committee as voting comm
- While the sign committee signs the data, voting committee do the same work and write to the data to the LEZ
- It looks like the if it works voting committee, why we dont have only voting, what is the points to separte? To make sense this, this must be a clear advantage such that voting committee uses a lighter signature etc. Maybe voting committee just write to the decentralized storage instead of LEZ, and enable only disputy solving and decentralized slashing mechanisms.
Iterative roadmap
There are many design choices and moving parts to build a decentralized oracle protocol. The most reasonable approach would be to find the fewest moving parts to build by assuming the other parts are trusted first. Then, each next iteration we replace the trusted parts the decentralized one modularly. Note that, this oracle mechanism will be tailored only for LEZ, and we may assume we can benefit from Logos module such as Logos identity or some reputation mechanisms that are used in other Logos modules.
As per this, first iteration trustless leader and aggregate all signatures
- iteration 1: trusted single leader as fetcher and signer PULL method
- iteration 2: offchain aggregation - trusted single leader as signer but collect prices from network
- iteration 3: onchain aggregation with 3 nodes automatically PUSH type.
- iteration 4 and others TBD later upon the findings from previous steps.