[PROPOSAL] RFP-020 — Kanon: RedStone Off-Chain Oracle Adaptor for LEZ

[diogofriggo]

RFP ID

RFP-020 — RedStone Off-Chain Oracle Adaptor for LEZ

Your Project Name

Kanon — RedStone Off-Chain Oracle Adaptor for LEZ

Kanon from the Greek κανών, a measuring rod and the root of the word "canon": a fixed standard others are measured against. That is what the adaptor produces, the canonical reference price (the RFP-019 canonical price account) that consuming protocols treat as authoritative.

Team or Organization Name

Equilibrium. We build, verify, and operate security-critical blockchain infrastructure: protocols, bridges, cryptographic systems, and the node software chains run on. We are an established engineering organization with a standing team, not a single contributor; we take on whole modules end to end, the model behind the audited cross-chain, validator-client, and cryptographic systems in Relevant Experience. For core infrastructure that DeFi will depend on, that means continuity, internal review, and one accountable party rather than hourly contracting.

Primary Contact

Olli Tiainen — olli@equilibrium.co

Team Members

The work is led by Equilibrium engineers with production SVM/Solana, Rust, and in-circuit-cryptography experience, backed by Equilibrium's wider ZK/cryptography and front-end teams.

• Diogo Friggo, Rust Engineer (lead, full-time). LinkedIn · Telegram @diogofriggo · Discord diogofriggo. Built a FROST threshold signature scheme from primitives to get past Aleo's in-circuit signature-verification limit (its contract language produced circuits that could not verify many signatures on-chain). That is the same in-circuit cost problem RFP-020 confronts on RISC0. Also added Solana as a data-availability adapter in the Sovereign SDK, a rollup framework whose zkVM proving backend is RISC0. SVM/Solana program development at the protocol and smart-contract (bare and with Anchor) levels; currently on Equilibrium's long-running Solana P2P network- and protocol-testing engagement across the Agave and Firedancer validator clients (public gossip-protocol spec: github.com/equilibriumco/solana-spec). Role: verification core, SPEL programs, and the cost-measurement track (with M0 ramp-up on RISC0 cost tooling against the LEZ runtime).
• Guilherme Felipe da Silva, Rust Engineer (full-time). LinkedIn. Built the Solana side of the Axelar <-> Solana cross-chain messaging integration (on-chain SVM programs plus relayer; the stack underwent external third-party security audits). Broad Rust systems experience. Role: SVM program engineering and DeFi security, the security test track, and the relayer.
• SDK, mini-app, CLI, and ZK/cryptography review: staffed from Equilibrium's front-end and ZK/cryptography teams (the same teams behind our wallet-SDK and shielded-pool/ZK work in Relevant Experience).

Project Summary

We will deliver the full RFP-020 scope: a push aggregator and a public-mode pull library over one shared verifier-core, plus the relayer, SDK, CLI, mini-app, two reference consumers, and the day-one BTC/ETH/SOL/XMR/ZEC USD feeds on devnet/testnet. We also take on the Servicing requirement in full: we operate the day-one feeds under the SLA in Servicing and SLA from software readiness through March 2028, included in the budget, backed by the measured 99.97% monthly uptime of the managed infrastructure we already run (see Relevant Experience). The XMR/USD and ZEC/USD feeds are first-class here: a verified, manipulation-resistant price layer is what any privacy-coin DeFi on LEZ (synthetics, collateralized positions, liquidation) ultimately depends on. This summary focuses on what is specific to our delivery rather than restating the RFP: how we structure the verifier so cost is measurable and a precompile swap stays local, how we handle dependencies that have moved since the RFP was written (table below), and the prior work behind the cost-measurement deliverable.

Cost measurement carries the RFP's open question. On Aleo we implemented FROST from primitives because the chain's circuits could not verify an M-of-N signer set on-chain, the same in-circuit bottleneck RFP-020 measures on RISC0; we have also implemented secp256k1-family verification from primitives. That work builds the judgment this deliverable needs: what to measure in a proving system, and which lever moves the cost. The RISC0-specific cost tooling is the M0 ramp-up, starting from a stack (the Sovereign SDK) whose proving backend is already RISC0. We will measure the in-program path per component and per mode (compute units, RISC0 proof time, proof size), reproducibly from the test suite, and report the delta a native precompile would close.

We checked each dependency against the live runtime; current status below.

Dependency	RFP-020 text	Current status	Effect on this work
RFP-001 admin authority library	"currently in development"	Open and contested: multiple proposals and competing open SPEL PRs take different approaches; none merged or in a tagged release (SPEL latest is v0.5.0)	The admin check sits behind our own thin admin shim/trait, so whichever approach lands upstream is a localized integration. M1 confirms the interface to build against and pins to it; if none has merged by M1, we pin the shim's minimal admin implementation and integrate the standardized library when it lands (Post-Delivery item 2)
RFP-019 canonical price account standard	soft dependency	open	We populate the standard if shipped; otherwise define a forward-compatible minimal struct (append-friendly layout) and re-export RFP-019's when it lands, with no consumer break
LP-0012 structured events	soft blocker, closed	closed (delivered)	Emit via the canonical lez-events mechanism directly; no interim adapter
On-chain clock / block timestamp	not addressed	A LEZ clock program exists (per-block timestamp via a clock account); ergonomic SPEL access is pending (open PR logos-co/spel#227)	maxAge reads go through one TimeSource trait that reads the clock account directly today, switching to the ergonomic accessor when it lands
secp256k1 + keccak256 precompile	out of scope / follow-on	not present	The in-program RISC-V path is the deliverable; the verifier's swap trait keeps a future precompile a localized change

Technical Approach

1. Stack and build model

Written in Rust against the SPEL framework (the Anchor-equivalent for LEZ), compiled to RISC0 zkVM guest binaries. The signature path uses established, widely-used crates (k256 for secp256k1 ECDSA recovery, tiny-keccak for keccak256) rather than hand-rolling cryptography. Both are crates RISC0 provides accelerated forks of (risc0/tiny-keccak, risc0/RustCrypto-elliptic-curves); where the accelerated path is available we use and pin those tags, and the M0 cost baseline measures the path that actually ships so the numbers are not distorted by a slower fallback. The tiny-keccak accelerator currently sits behind a RISC0 unstable feature flag, which is why its accelerated-vs-baseline contribution is one of the M0 numbers we report. Crate versions are pinned so the measured numbers do not drift under an upstream bump. Pure state-transition and verification logic runs in the guest; clients, IDL generation, and integration tests are host code. Layout follows the scaffold (logos-co/scaffold) / lgs toolchain and is validated against the logos-execution-zone and lez-programs reference repositories; any riscv32 cross-compilation issues are resolved in M0. All code is dual-licensed MIT + Apache-2.0, a hard RFP requirement, so verifier-core draws only on compatibly licensed sources. The RedStone payload decode is built on the permissively licensed RedStone Rust SDK (Boost Software License 1.0, MIT/Apache-compatible, and the same SDK RedStone ships for its non-EVM connectors) where it is guest-compatible, and implemented clean-room from RedStone's published wire-format specification where it is not, so our own code stays MIT + Apache-2.0 with the SDK consumed as a declared dependency rather than vendored. We do not copy or port RedStone's EVM connector, parts of which are BUSL-1.1 and cannot ship in an open-source deliverable; where byte-level conformance needs checking we use the connector only as a black-box oracle against published test vectors, never reading or porting its source. The repo carries a NOTICE / third-party-license file, and the M1 done-gate runs a cargo deny license check that fails CI on any BUSL or copyleft dependency, transitive ones included, since the Rust SDK sits in a monorepo alongside BUSL packages.

kanon/
  verifier-core/       # no_std: RedStone package decode, ECDSA recovery, keccak256,
                       #   M-of-N threshold, maxAge/asset/value checks, behind a
                       #   VerifierBackend trait (in-program | precompile)
  methods/guest/       # RISC0 guest binary
  aggregator-program/  # SPEL push program: verify -> median -> canonical price account
  pull-lib/            # public-mode pull: same verifier-core, typed-error API
  kanon-idl/          # SPEL IDL + generated bindings (standalone artifact)
  kanon-sdk/          # SDK: push submit, account read, pull verify
  kanon-relayer/      # Logos Core headless daemon (module)
  kanon-app/          # Basecamp mini-app (feed dashboard + pull dry-run panel)
  reference-consumers/ # aggregator-read + public-mode pull examples
  examples/            # runnable scripts against the local sequencer

2. Single verification core behind a precompile-swap trait

verifier-core is the one place signature verification happens. It decodes the RedStone data package (feedId, value, timestamp, signer set), recovers each signer with secp256k1 ECDSA over a keccak256 message hash, enforces the configurable M-of-N threshold (default 3-of-N), and validates maxAge, asset identity, and value sanity. The recovery/hash work sits behind a trait:

/// Generic over the signature scheme and the execution path. RedStone today is
/// secp256k1 ECDSA over keccak256; the same trait admits a precompile-backed impl
/// (same scheme, faster path) or a Schnorr/BIP-340 impl (the FROST-friendly scheme
/// for the private-pull follow-on). Schnorr has no key recovery, so that backend
/// implements `recover` as verification against the claimed signer, returning it
/// on success.
trait VerifierBackend {
    type Signature;   // e.g. ECDSA (r, s, v), or a Schnorr signature
    type Signer;      // recovered identity, e.g. an Ethereum-style address
    type Error;

    fn hash(&self, data: &[u8]) -> [u8; 32];   // scheme digest: keccak256, tagged SHA-256, ...
    fn recover(&self, digest: &[u8; 32], sig: &Self::Signature)
        -> Result<Self::Signer, Self::Error>;
}

The default backend is in-program secp256k1 ECDSA over keccak256 (k256 + tiny-keccak). Because the trait is generic over the scheme and the execution path, a follow-on can add a precompile/syscall backend (same scheme, faster path) or a Schnorr/BIP-340 backend (the FROST-friendly scheme for the private-pull follow-on) as another impl, with no change to the aggregator, the pull library, the SDK surface, or the tests. That keeps the precompile swap the RFP asks for to a one-file change.

The aggregator program (push) and the pull library are both thin callers of verifier-core: one audited implementation, two modes, common cost and audit surface.

3. Push aggregator, canonical price account, admin integration

The SPEL aggregator calls verifier-core, takes the median across signers, and writes the canonical RFP-019 struct: base_asset, quote_asset, price, timestamp, RedStone source constant, and confidence = 0 (RedStone publishes none). Feed registration (asset id, M-of-N, authorized signer set), signer-set update on RedStone roster changes, and deregistration are admin-gated via the RFP-001 admin authority, integrated through SPEL. Feed registration is atomic: a partial failure leaves existing registrations intact, and a per-feed upstream error does not affect other feeds on the same node.

4. Public-mode pull library

The same verifier-core, exposed for inline use by a public consumer program. Given a signed payload, a configured (dataServiceId, feedId, authorized signer set, M-of-N, maxAge), and the consumer's expected (base_asset, quote_asset), it returns the verified price and timestamp or a typed error (invalid signature, signer not in set, threshold not met, stale package, asset mismatch, malformed package, zero or negative value, and value-scaling/exponent out of range). It has no dependency on the aggregator account: a pull-only consumer integrates without registering a feed. Per the RFP's security requirement, the signer set is supplied by the consumer (or a consumer-owned config account) and is never sourced from the payload.

5. Time and staleness source (the maxAge time dependency)

maxAge enforcement (rejecting a package older than a configured age, and rejecting replays of stale packages) requires a current-time reference on-chain. LEZ exposes one through a clock program account carrying a per-block timestamp; what is still pending is ergonomic SPEL access to it (open PR logos-co/spel#227). All current-time reads go through one TimeSource trait, the same way we would handle any clock-dependent logic:

• The default backend reads the LEZ clock account directly, so staleness is enforced against a real on-chain timestamp from day one.
• When ergonomic SPEL access lands, switching the backend is a single trait swap, with no change to the package format, the price-account layout, or the SDK.
• If a clock read is ever unavailable, the handler returns a typed, actionable error rather than silently accepting an unverifiable age.

We confirm the exact mechanism against the live runtime in M0 and document what time source the maxAge check relies on.

6. Cost measurement methodology (primary deliverable)

We instrument verifier-core to report, per component and per mode:

• Components: per-signer ECDSA recovery, keccak256 hashing, package decode, signer-set membership check, and (push only) canonical price-account write and feed registration.
• Modes: the full 3-of-N aggregator write, and the full 3-of-N public-mode pull read, with the per-read cost a pull consumer incurs reported explicitly.
• Units: compute units, RISC0 proof time, RISC0 proof size, and per-update / per-read bytes.

RISC0 performance depends heavily on which implementations of ECDSA recovery and keccak are used, so we measure both the accelerated path (where RISC0 provides one) and the non-accelerated baseline, and report keccak's contribution to proof size separately. That keeps the push-vs-pull and precompile-delta numbers anchored to the path that actually ships.

Numbers are produced by the test suite so they are reproducible, are tagged with the exact testnet version they were taken against (the per-transaction budget can change between releases), and are characterized against the budget in force at delivery. We then report the in-program vs native ECDSA + keccak256 precompile delta separately per mode, anchored to the reference points the RFP cites (RedStone EVM end-to-end 50K–100K gas; per-recovery costs on chains that expose a native primitive), because push and pull amortize a precompile speed-up differently.

7. Security analysis and tests

Every hard requirement maps to at least one test, for both modes. The security surface and its tests:

• Signer authority: reject any signer not in the authorized set (both modes). Push: the stored signer set is updatable only by the admin authority (RFP-001), and that update path is itself tested. Pull: the signer set is consumer-supplied and must not be accepted from the payload; negative tests assert this.
• Threshold: M-of-N enforcement including boundary cases (exactly M, M-1).
• Staleness / replay: maxAge rejection, stale-package replay, and (push) signer-set update delays, with a documented minimum recommended maxAge and a manipulation analysis covering signer compromise, replay, and update races.
• Input sanity: zero/negative value, malformed package, asset-identifier mismatch, and decimal-exponent / price-scaling bounds. The RedStone value carries a decimal exponent; scaling it into the canonical price-account representation must not silently overflow or truncate. Out-of-range exponents return a typed reject rather than an arithmetic panic. Guarded and tested in both modes.
• Pull-in-consumer: pull tests exercise the library inside the public-mode pull reference consumer, not only as a unit test.

We bring DeFi-security and property-based/verification practice (Move Prover mutation tooling, audited cross-chain stacks) to this track; high-value invariants in verifier-core are property-tested in CI.

Production hardening. The manipulation analysis flags operational safeguards a production deployment should add. One of them, an admin emergency pause (per feed), we pull into scope (M2): since we operate the feeds under the Servicing SLA, the pause is our own first mitigation tool for a suspected price-integrity fault. The rest we can deliver as a follow-on: scheduled effective-time and a grace window on signer-set rotation, an on-chain degraded mode, and relayer-side registry monitoring with signer-change alerting. The current design leaves room for each (the admin authority, the TimeSource clock, and the relayer's monitoring are already in place), so none requires a redesign to add later.

8. HTTPS/DDL data path and the relayer

Signed packages are fetched from RedStone's Data Distribution Layer (DDL) over HTTPS, not P2P. We document the censorship, liveness, and pull-mode gateway-IP caveats, and ship the operator mitigations: parallel DDL gateway queries with first-success selection, RedStone private-gateway override where available, and a recent-price fallback policy, without claiming any of these removes the structural centralization. The relayer is a Logos module with a Logos Core headless daemon: configurable dataServiceId (default redstone-primary-prod), per-feed heartbeat and deviation triggers, retry with back-off, structured logging including the on-chain rejection reason, wallet-balance monitoring, and clean shutdown. The operator journey (install -> configure -> run -> monitor) is documented in full, including the RedStone Terms of Use notice: the party that runs the relayer is the party bound by those Terms. During the operating period that party is Equilibrium (Servicing and SLA); when operation later moves to another operator, whoever runs the software becomes the bound party.

9. Fee model

Per the RFP, the adaptor program bakes in no fee policy: subsidize, per-read, per-update, treasury, burn, or zero are all left to deployers, and the program forecloses none of them. Cost incidence is as the RFP describes (per-update in push, per-read in pull).

10. Conformance to the canonical price account standard

The adaptor populates the RFP-019 struct (re-exported, not forked); cross-source policy stays with the consumer. If RFP-019 has not shipped the struct at delivery, we define a minimal forward-compatible struct using append-friendly account-data conventions, so a later RFP-019 release extends it without breaking consumers.

11. Applications: SDK, CLI, mini-app, reference consumers

• SDK for building Logos modules in both modes, with ergonomic helpers so a developer switches push <-> pull without changing payload handling.
• CLI covering both modes: submit a package to the push aggregator, query the canonical price account, register and deregister feeds, update signer sets, and an off-chain pull dry-run that reports the same typed error codes the on-chain library returns.
• Basecamp mini-app dashboard: live prices, signer set, threshold, latest timestamp, and staleness per feed, plus a pull dry-run panel that shows what the pull library would return without sending a consumer transaction. Figma designs ship with the app.
• Two reference consumers (aggregator-read and public-mode pull), both showing (base_asset, quote_asset) verification, staleness handling, typed-error handling, and the refuse-on-unavailable pattern (never fall back to an unsafe default), built on the SPEL push/pull hook enhancement (Usability 5).
• IDL for the program and the re-exported RFP-019 standard, via SPEL.

12. Requirement traceability

A traceability matrix in the repo maps every RFP-020 hard and soft requirement (Functionality 1–9, Usability 1–7, Reliability 1–4, Performance 1–3, all Supportability items, Adaptor Security 1–3, both soft requirements) to the section that implements it and the test that verifies it. CI runs the full suite against a standalone LEZ sequencer and is green on the default branch from the first code milestone onward. The matrix is reproduced here in condensed form so this document is self-contained:

Requirement	Implemented in	Verified by
F1 push-mode aggregator	§3	E2E push verify+publish against the sequencer (M2 gate)
F2 verification packaged as a library, callable in-program and consumer-side	§2	verifier-core unit tests exercising both call paths
F3 M-of-N signer threshold per feed	§2	threshold accept/reject tests
F4 RedStone data-package decode	§2	decode conformance tests against the published wire format
F5 canonical price account per RFP-019	§10	account-layout conformance tests (or fallback-struct tests)
F6 admin authority: register / update signer set / deregister	§3	admin-gated instruction tests incl. the update path
F7 BTC/ETH/SOL/XMR/ZEC USD feeds day-one	§3	feeds registered + exercised on devnet/testnet (M2 gate)
F8 relayer module	§8	headless end-to-end relayer run (M4 gate)
F9 public-mode pull verification library	§4	pull verified inside a reference consumer (M3 gate)
U1 SDK · U3 CLI · U4 IDL	§11	SDK/CLI command suites, both modes, against the sequencer
U2 Basecamp mini-app dashboard	§11	mini-app loads in Basecamp; dashboard flow tests
U5 SPEL push/pull feed-mode hook	§11	hook exercised from a fresh scaffold program in tests
U6 actionable errors on all failure modes	§2, §4	typed-error negative tests (stale, unknown signer, below-threshold, malformed)
U7 two reference consumers (one per mode)	§11	per-mode consumer E2E tests
R1 read-only price reads · R2 atomic registration · R3 per-feed isolation · R4 recoverable daemon	§3, §8	negative tests + relayer fault-injection/restart tests
P1 single-transaction verify+publish	§3	one-tx assertion in E2E
P2 cost measurement as primary deliverable	§6	M0 baseline + per-component/per-mode cost tables
P3 in-program vs precompile delta	§6	delta report per mode
Supportability S1–S7 (devnet/testnet deploy, sequencer CI, ≥1 test/req, README, 2 doc packets, Figma)	M2, M4–M5	CI green + deliverable checklist per milestone gate
Security 1 reject unknown signers · 2 admin-gated signer set · 3 recommended maxAge documented	§7, §5	security test set + maxAge recommendation in the security analysis
Servicing 1–5 (operating period, availability, cadence, incident response, reporting)	Servicing and SLA	monthly operating reports + dashboard read access, software readiness through March 2028
Soft 1–2: batched multi-feed verification; TWAP multi-source test	§13	stretch-scope tests, gated on the M0 cost result / RFP-019 availability

The full line-item matrix (every sub-requirement → section → named test) lives in the repo and is kept green in CI from the first code milestone.

13. Soft requirements (stretch)

The RFP's two soft requirements are in scope as stretch goals once the hard set is green. (1) Multi-feed batched verification: amortize calldata and signature recovery across multiple feeds in one instruction (analogous to Pyth's Perseus amortization); the shared verifier-core is structured to support batching. (2) Multi-source integration test against the RFP-019 TWAP tier: once the TWAP program is available, one consumer reading the RedStone price account (push) and one running public-mode pull, each paired with the TWAP account for the same pair, apply an example cross-source policy (primary/fallback, divergence cross-check) without the adaptor participating in that policy.

Milestones, Payout and Timeline

Six milestones, each with a done-gate that must pass before the next begins. Milestones run sequentially (M0 through M5). The central technical question, in-circuit ECDSA + keccak256 cost, is characterized first in a short, low-cost M0 cost baseline reviewed with Logos, so the rest of the build is calibrated to real numbers rather than assumptions. M0 shapes how we proceed (the operating envelope, push-vs-pull emphasis, and whether to also recommend a precompile follow-on); it does not decide whether the adaptor ships. The RFP asks for both a working adaptor and the cost picture, and the VerifierBackend trait keeps a later precompile swap a localized change, so a high in-program cost tunes the delivery; it does not end it.

#	Milestone	Key deliverables	Done gate	Duration
M0	Cost baseline	Cost-only spike on a standalone sequencer: single-signer ECDSA + keccak256 in-circuit cost (CU/proof time/proof size) on the accelerated path (where RISC0 provides one) vs the software baseline, plus a first in-program-vs-precompile delta sketch; toolchain + sequencer version pinned; reproducible from a benchmark target	Cost numbers delivered and reviewed with Logos: agree the operating envelope (in-program path, heartbeat width, push-vs-pull emphasis) and whether to also recommend a precompile follow-on	1 wk
M1	Foundations, verification core & conformance	Public repo, lgs build green CI, riscv32 build resolved; remaining spikes documented against logos-execution-zone source: (a) RFP-001 admin-authority: the interface to build against (or the shim fallback if none has merged), (b) maxAge/time-source mechanism on the live runtime, (c) RFP-019 struct availability; verifier-core (decode, ECDSA recovery, keccak256, M-of-N, maxAge/asset/value, exponent/scaling bounds) behind the VerifierBackend trait; RFP-019 price-account write (or forward-compatible fallback); per-component cost numbers; unit tests for all accept/reject paths	Repo + green CI + 3 spikes with exact source refs; all M1 tests green; cargo deny license gate green; component cost table published	2.5 wks
M2	Push aggregator, admin, feeds, security	SPEL aggregator writing the canonical account; RFP-001 admin integration (register/update-signer-set/deregister, update path tested); admin emergency feed-pause instruction (our first mitigation lever as the servicing operator); BTC/ETH/SOL/XMR/ZEC vs USD registered on devnet/testnet; push-write cost measurement; full security test set	E2E push verify+publish green on standalone sequencer; security tests pass; CI green	2 wks
M3	Public-mode pull + reference consumers + cost	pull-lib with typed errors and no aggregator dependency; aggregator-read and public-mode pull reference consumers (refuse-on-unavailable); per-read pull cost; in-program vs precompile delta report per mode	Pull verified inside the reference consumer; pull cost + delta published; CI green	1.5 wks
M4	Relayer, SDK, CLI, mini-app	Logos Core headless relayer (parallel gateways, heartbeat/deviation, retry/back-off, structured logging, wallet monitoring, clean shutdown); SDK; CLI (incl. feed registration/deregistration and signer-set updates) with off-chain pull dry-run; Basecamp mini-app (dashboard + pull dry-run panel); SPEL push/pull hook enhancement; IDL; Figma	SDK/CLI exercise both modes against sequencer; mini-app loads in Basecamp; relayer runs headless end to end	2 wks
M5	Testnet, docs, audit-ready bundle	Deployed/verified on current LEZ testnet; full suite green in CI against the sequencer; README; SDK + CLI doc packets (incl. "Recommended Consumer Pattern" and a cost-grounded "When to use push vs pull" guide); traceability matrix; audit-ready artifact bundle; servicing go-live: redundant relayer deployment, monitoring/alerting, and the on-call rotation active (Servicing and SLA)	Testnet smoke + regression green; doc packets submitted for review; bundle delivered	1 wk

Milestones run sequentially (M0 through M5). M0 is a small ~1-week cost-only spike, so the key in-program ECDSA + keccak256 numbers are on the table early and the rest of the build is tuned to them. The overall calendar sits at the top of the RFP's 6–10-week estimate, reflecting first-contact ramp-up on LEZ/SPEL/RISC0 and the dependency sequencing in the table above. Per the RFP's updated Timeline Expectations, software delivery is followed by the operating period from software readiness through March 2028, during which we run the feeds under the Servicing and SLA section below, included in the same fixed budget.

Optional external audit (not in the core budget): we recommend a separately scoped audit + remediation track covering verifier-core, the admin/update paths, and the M-of-N/threshold logic, since the deliverable implements cryptographic verification and admin-gated state. We ship audit-ready artifacts in M5 and remediate critical/high findings before any mainnet recommendation. Candidate firms are the tier Logos's own RFPs cite as examples (OpenZeppelin, Trail of Bits, Spearbit/Cantina, ChainSecurity, Certora, Halborn). Note RFP-020 does not itself require an audit.

Servicing and SLA

Per the Servicing requirements added to RFP-020, Equilibrium operates the push-mode feed infrastructure for BTC/USD, ETH/USD, SOL/USD, XMR/USD, and ZEC/USD from software readiness through March 2028, on devnet/testnet and then mainnet once available. Servicing is included in the fixed budget at no additional cost. Operating managed blockchain infrastructure under an SLA is existing Equilibrium practice, not new scope: our managed Aleo infrastructure runs at a measured 99.97% monthly uptime (see Relevant Experience), above the target we commit to here. Per Servicing 2, the numbers below are our proposed contractual targets.

1. Operating period. We run the relayer daemon (Functionality 8), keep the update-submission wallets funded, and keep the authorized signer sets current with RedStone roster changes, from software readiness through March 2028. The deployment uses only the documented operator journey: no private configuration or bespoke infrastructure, so another operator can take over at any point from the runbook without a new deliverable, with a handover package delivered at the end of the period.
2. Feed availability. 99.9% monthly per feed (roughly a 43-minute monthly downtime budget), measured as the fraction of the heartbeat schedule for which a fresh, valid on-chain price within maxAge is available, with maximum staleness bounded at 90 minutes (1.5x heartbeat). Monitoring measures the end of the chain, the canonical price account itself, not relayer process liveness.
3. Update cadence. 0.5% deviation threshold and 1-hour heartbeat on all five pairs, the RFP's recommended defaults. If a specific asset proves too thin or volatile to sustain that cadence economically, we propose a widened band for that feed in the monthly report before changing it.
4. Incident response. Automated staleness, wallet-balance, and liveness alerting drives a three-level on-call escalation with a named contact: L1, the delivery engineers (primary rotation); L2, Equilibrium's infrastructure/operations team; L3, the engagement lead. Acknowledge within 1 hour, mitigate within 4 hours. Mitigation means restoring a safe state, not necessarily a code fix: for a suspected price-integrity fault the first action is pausing the affected feed via the admin emergency pause (M2) while the root cause is established. Any breach of the availability target receives a root-cause summary and corrective-action record.
5. Reporting. Monthly operating reports covering per-feed uptime against target, cadence adherence, update and rejection counts, incidents and resolution, signer-roster status, and wallet funding, plus read access for the Logos ecosystem team to the live monitoring dashboard: the Basecamp mini-app (M4) is the off-chain feed dashboard, backed by our operator-side monitoring.

Resilience. At least two relayer instances in isolated cloud failure domains, parallel DDL gateway queries with first-success selection (§8), and continuous monitoring of per-feed on-chain freshness, process liveness, and submission-wallet balance.

Software maintenance during the operating period. As the operating party we are the first consumer of every fix, so the software is maintained through March 2028, severity-tiered: critical defects (wrong or stale price publication, feed down) are acknowledged within 1 hour, brought to a safe state within 4 hours (feed pause where warranted), and fixed on a days scale with a root-cause summary; non-critical defects and dependency/runtime upkeep (LEZ/SPEL/RISC0 version bumps, RedStone wire-format changes) are triaged into scheduled maintenance. LEZ is pre-mainnet and its runtime will evolve during the operating period; keeping the adaptor current across those upgrades is part of this commitment.

Exclusions. The SLA excludes time attributable solely to a confirmed target-network outage preventing all conforming submissions, simultaneous unavailability or invalid output from all configured RedStone gateways (a single failed gateway is ours to absorb via the parallel-gateway path), Logos-approved maintenance windows, and force majeure. Excluded events are still monitored and reported.

Terms of Use and fees. During the operating period Equilibrium runs the relayer and is therefore itself the party bound by the RedStone Terms of Use; we determine and comply with any commercial-agreement requirement as the operating party. Because the LEZ mainnet fee model is not yet published, on-chain transaction fees for feed updates are reimbursed at cost as a pass-through, with a fee ledger in the monthly report; relayer servers and monitoring are included in the fixed price.

Total Requested Budget (USD)

to be agreed between the parties

Relevant Experience

Equilibrium brings the skill set RFP-020's recommended profile names: signature-verification cryptography, SVM-native program engineering, RedStone-adjacent primitives, DeFi-security/verification practice, and SLA-backed infrastructure operations, across delivered, linkable engagements. The central deliverable here is in-circuit cryptographic cost: knowing what to measure, how to structure the verifier so the cost stays controllable, and which lever actually moves it. We have shipped that class of work across a broad range of proving systems, including Aleo's SnarkVM circuits, Groth16 and Halo2 (ZAIR), and STARK (our Starknet full node). RISC0 is a zk-STARK zkVM in that same family, not a proving system we are approaching cold. We have not shipped an oracle adaptor before; LEZ/SPEL and the RISC0-specific cost tooling are the scoped M0–M1 ramp-up.

Signature-verification cryptography (the core of this RFP)

• FROST, built to beat an in-circuit signature-verification limit (Aleo/Axelar integration). Aleo is a ZK/privacy chain whose smart-contract language compiles to circuits, and verifying an M-of-N signer set in-circuit was infeasible: the cost scaled with the signer count N, so checking a full set on-chain blew past the circuit's budget. The fix (lead engineer's work, initial proof-of-concept from scratch) was a threshold-Schnorr (FROST) scheme that collapses the M-of-N check from N in-circuit verifications into a single aggregated signature the circuit verifies once, taking the cost from linear in the signer count to constant. That is the same class of in-circuit cost problem RFP-020 measures on RISC0, where ECDSA + keccak256 is the bottleneck, and the same lever the RFP names (FROST-BIP340) for the private-pull follow-on.
• Sovereign SDK, work inside a RISC0-backed stack. Added Solana as a data-availability adapter (protocol-level and program work) in the Sovereign SDK, a rollup framework whose zkVM proving backend is RISC0, the same zk-STARK + RISC-V zkVM RFP-020 targets. This is the source of our direct RISC0 familiarity and is also relevant to LEZ's SVM-style account/program model, SPEL, and IDL generation. The M0 ramp-up builds guest-circuit cost tooling on top of that familiarity.

SVM / Solana-native program engineering

• Axelar <-> Solana GMP stack (Axelar, public). Solana side of Axelar's cross-chain messaging: on-chain SVM programs, off-chain relayer, and deployment tooling; external third-party security audits. github.com/equilibriumco/axelar-amplifier-solana, github.com/equilibriumco/axelar-solana-relayer.
• Eclipse (Solana <-> Aleo ZK bridge) (Aleo, public). Open-source prototype ZK bridge: a modified Solana validator, on-chain SVM programs, and an off-chain Rust service (SnarkVM). This is the integration the from-scratch FROST work above was built for. github.com/equilibriumco/eclipse.
• Solana P2P network and protocol testing. Long-running multi-client resilience testing across the Agave and Firedancer clients; public gossip-protocol spec at github.com/equilibriumco/solana-spec.
• IBC on Solana. Solana IBC programs, an M-of-N attestation light client, and relayer infrastructure with a working Solana -> Cosmos -> Solana roundtrip; external third-party audit. Relevant to M-of-N verification and program-owned flows.

Privacy-preserving protocol & verification work

• ZAIR, Zcash shielded cross-ecosystem claim (Zcash Community Grants, public). Per-note ZK proofs of ownership/unspentness without revealing the nullifier, across Sapling (Groth16) and Orchard (Halo2). github.com/equilibriumco/zair.
• Move Prover mutation-testing tooling (Aptos Foundation, public). Mutation testing for formal specs and test suites, the same verification discipline behind this proposal's property-tested invariants. github.com/equilibriumco/move-mutation-tools.
• Pathfinder (StarkWare, public). Production open-source Rust full node for Starknet with independent state verification; maintained since 2022. github.com/equilibriumco/pathfinder.

Production infrastructure operations under SLA (the Servicing requirement)

• Managed Aleo infrastructure, 99.97% measured monthly uptime. We operate Aleo infrastructure as a managed service with 24/7 monitoring, alerting, and an on-call rotation, running at a measured 99.97% monthly uptime, above the 99.9% per-feed target this proposal commits to. The same monitoring and escalation practice backs the Servicing SLA here.
• Long-lived operational engagements. The Solana network- and protocol-testing engagement above runs continuously across the Agave and Firedancer clients, and Pathfinder, our production Starknet full node, has been maintained and released continuously since 2022. Operating long-lived blockchain services and their monitoring stacks is standing Equilibrium practice, not new scope taken on for this RFP.

Front-end / wallet SDK

• Multi-chain self-custodial wallet SDK. Wallet-SDK and front-end engineering with DEX-aggregator and lending integrations, relevant to the SDK and mini-app deliverables.

Post-Delivery Plan

1. Handoff bundle. Cost-measurement report (both modes, per component, with the precompile delta), test/traceability matrix, deployment runbook, and the relayer operator guide (including the RedStone Terms-of-Use notice), handed to Logos and to consuming protocols. At the end of the operating period, the servicing handover package: runbook, infrastructure definitions, and monitoring configuration, so another operator takes over without a new deliverable.
2. Maintenance through the operating period (through March 2028). As the operating party we are the first consumer of every fix, so the software is maintained for the whole servicing period under the severity-tiered commitment in Servicing and SLA: bug triage and dependency upkeep (RFP-001 / SPEL / LEZ-runtime version bumps, the TimeSource switch to the ergonomic clock accessor when it lands, and the RFP-019 struct re-export when it ships), plus integration support for the first consumers pairing RedStone with the RFP-019 TWAP tier.
3. Precompile follow-on readiness. Because the verifier sits behind the VerifierBackend trait, if the cost measurement warrants a secp256k1 + keccak256 precompile RFP, integrating it is a localized change we are positioned to take on as separate scope.
4. Foundation for the privacy-coin DeFi roadmap. This adaptor is a deliberately scoped first module. The manipulation-resistant feeds it secures (XMR/USD and ZEC/USD in particular) are the price layer that synthetics and swap work on the Logos roadmap (e.g. sXMR/sZEC, the cross-chain and synthetics direction) will depend on. We would take that on as follow-on scope, building on the verifier, relayer, and SDK delivered here.

Permissions and Consent

• I confirm Logos may contact me using the primary contact information provided above for follow-ups and next steps.
• I consent to Logos using information from this proposal publicly such as blogs, case studies, social posts, or analytical reporting. Redactions can be requested at any time.

Program Requirements

• We understand this project must be open-sourced under the MIT and Apache 2.0 Licenses unless explicitly approved otherwise.
• We are prepared to deliver milestone-based outcomes.

[NthMOMENT]

@diogofriggo saw the M0 cost baseline requirement for ECDSA + keccak256 in RISC Zero.

For reference: I run a dedicated RISC Zero proving backend (RTX 4090, CUDA 12.8, RISC Zero 3.0.5) and published benchmark results today for a related workload NIST PQ signature verification inside RISC Zero zkVM.

SLH-DSA (SHA-256-heavy, similar profile to keccak256): CPU 28m 51s → GPU 16.22s, 107x speedup.

Raw Logs: https://github.com/NthMOMENT/kaspa-pq-bench-results

If independent GPU numbers would be useful for your M0 baseline, happy to run your guest ELF. No strings attached.

[jzaki]

Appreciating the attention-to-detail of your proposal.
"Note RFP-020 does not itself require an audit" Can you please expand upon what you mean here?

[diogofriggo]

Appreciating the attention-to-detail of your proposal. "Note RFP-020 does not itself require an audit" Can you please expand upon what you mean here?

Thanks for the kind words. It means "while audited code has been mentioned in RFP 020, it was never listed as a hard requirement" which is why I added the "Optional audit external audit" section

[hackyguru]

After a careful review, we are happy to go ahead with your proposal for RFP-020. A discord thread with the points of contact at Equilibrium will be created shortly. Please be informed about the Terms and conditions before we head to the next steps.