This post summarizes the IFT Research call that was held on 6th May in two parts with @fryorcraken.
1. Oracles on LEZ: TWAP and Off-Chain Adaptors (RFP-019 + RFP-020)
LEZ’s lending (RFP-008) and stablecoin (RFP-013) primitives
cannot function without a price oracle. These two RFPs fill that gap.
Why Two RFPs?
RFP-019 — On-chain TWAP
Computes geometric mean TWAP from DEX pool accumulators.
Defines the canonical price account standard.
Blocked on DEX (RFP-004) but the standard can be developed in parallel.
RFP-020 — RedStone Off-chain Adaptor
Implements secp256k1 ECDSA + keccak256 verification as RISC-V
program code inside RISC0. Push-mode aggregator pattern: verification
runs once on the write side, result lands in a public price account,
private accounts read it with zero signature cost.
Why RedStone?
XMR/USD + ZEC/USD feeds available, no bridge dependency,
self-serve and permissionless. Pyth requires Wormhole,
Chainlink requires business engagement.
Benchmark (CPU-only Ryzen 9 7940HS)
The benchmark based on lez-signature-bench:
| Scheme | Cycles/sig | E2E private TX (3-of-N) |
|---|---|---|
| ECDSA P-256 | 198K | 4:58 |
| Schnorr secp256k1 | 271K | 5:22 |
| ECDSA secp256k1 | 303K | 7:26 |
| Ed25519 | 803K | 11:09 |
| LMS | 2681K | 8:56 |
For now, no scheme hits sub-30s on CPU. Private-execution pull mode
is therefore not viable. Push-mode is not a preference —
it is a structural requirement.
Key Design Decisions
- Public-mode aggregator amortises verification cost across all reads
- Private accounts compose by reading the public price account
- Precompile is a cost-conditional follow-on, not a precondition
- Cost measurement on real LEZ devnet is RFP-020’s first deliverable
2. Logos Oracle Network: A Future Mechanism
A forward-looking architecture where Logos nodes themselves
act as oracle publishers — eliminating dependence on external
oracle networks entirely.
Architecture
Four stages:
-
Fetch — Each Logos node independently pulls price data
from sources (Pyth, RedStone, Chainlink, primary resources) -
Consensus — Hashgraph-like binary voting among nodes.
Each node votes YES/NO based on whether the proposed price
falls within its own ±X% tolerance band. Voting and signing
collapse into a single step: a node that votes YES signs
immediately. No separate signing round needed. -
Write — M-of-N signed price package is submitted to LEZ.
The signature scheme is freely chosen — whatever is most
performant for LEZ verification. -
Verify — LEZ verifies the signatures on-chain.
Why This Architecture Enables Private Pull
The key insight: because Logos nodes control both signing and
the choice of signature scheme, they can adopt schemes that are
cheap to verify inside RISC0.
BLS aggregation — ~2M cycles (constant regardless of signer count),
but expensive due to pairing and not quantum-safe.
LMS (hash-based) — ~2.2K cycles for verification using RISC0’s
existing SHA-256 precompile. 10 signers = ~22K cycles total. Note that this cycle counts are not verified by an implementation.
No aggregation but verification is so cheap it doesn’t matter.
Quantum-safe by construction.
Compared to the current RedStone adaptor (303K cycles/sig),
LMS verification is roughly 100x cheaper per signer —
making private-execution pull mode viable for the first time.
Open Problems
- Consensus: binary voting requires a deviation tolerance
parameter and a quorum threshold. Propose is unnecessary
if voting is present — nodes already have their own data. - Sybil resistance: eligibility criteria for oracle role
- LMS state management: each keypair has a fixed signing
budget (h=10 → 1024 signatures). Crash recovery and
keypair rotation must be handled. - Write coordination: who submits to LEZ after consensus,
and what is the fallback if they go offline? - Incentivization and bootstrapping: out of scope here
but required before deployment.