In short

  • An oracle adaptor bringing RedStone price feeds to LEZ, being built by Equilibrium under the Logos RFP programme.
  • It will check that price updates carry valid signatures from authorised providers and are recent, then make those prices available to LEZ applications.
  • Five feeds: Bitcoin, Ethereum, Solana, Monero, and Zcash against the US dollar.
  • Two ways to use it. Push mode maintains a shared price that private-execution applications can read. Pull mode verifies an update inside your own transaction, and works only for public execution.
  • Built for lending protocols, crypto-backed stablecoins, and anything on LEZ that needs prices from markets the chain can’t see.
  • Open source under MIT and Apache 2.0. The work is in progress: this post describes Kanon as it will be at delivery.

If you’re building a lending protocol, you need to know what its collateral is worth. A stablecoin backed by crypto assets needs those prices too. Both depend on data from markets outside the application, which is what an oracle provides. On a new chain, applications need those prices before enough local trading exists to produce them.

We’re using the Logos stack to build Kanon, an oracle adaptor that brings RedStone price feeds to the Logos Execution Zone. It’s part of the Logos RFP programme, and it covers Bitcoin, Ethereum, Solana, Monero, and Zcash against the US dollar. The Monero and Zcash coverage is particularly worth noting, given Logos’s design as a private-by-default stack.

Kanon checks signed updates from RedStone, confirming they carry the required signatures from authorised providers and are recent enough to use. What an application gets is a verified price: one that a defined set of RedStone signers signed at a known time, and that nobody between them and the chain could have altered.

How you use it

There will be two ways to consume the feeds. In push mode, a relayer submits an update to the adaptor, which verifies it and stores a shared price. The set of signers the adaptor accepts is administered on-chain, and anyone can inspect it. Applications running in private execution read that public price while keeping their own actions private. In pull mode, an application supplies a signed update and verifies it inside its own transaction, against a signer set the application configures itself. That second mode is public execution only.

Kanon is one source in a broader oracle setup. Applications can pair it with the on-chain time-weighted average prices planned under RFP-019.

Alongside the adaptor there will be an SDK, command-line tools, and example integrations. A dashboard in Logos Basecamp will show current prices and when each was last updated. The documentation will cover setup and integration, including what to do when a price is too old or unavailable.

What you’re trusting

An application using a Kanon price relies on two checks: that the price was signed by enough signers from an authorised set, and that it falls inside a bounded time window. Not that the price is correct. Correctness rests on RedStone’s signers, and the signer set is where you decide how much that’s worth. In pull mode, you configure that set yourself. In push mode, it’s administered on-chain and updated when RedStone’s roster changes; your application reads the resulting price and can inspect the set it was checked against. What Kanon removes is the need to trust anything else about the data’s integrity: not the sender, not the gateway, not a field claiming to be a data service.

One thing to know before you integrate: verification fails closed. A package from a signer outside the authorised set is rejected, not skipped, and so is a package that falls short of the signer threshold. In pull mode that puts a responsibility on you: when RedStone rotates its signers, your set has to follow, or valid updates stop verifying. The documentation will cover the signer-set mechanics, freshness bounds and failure behavior, and a manipulation analysis will cover signer compromise, replay, and rotation.

What verification costs

Checking a RedStone update means verifying signatures and hashing inside RISC0, the zero-knowledge virtual machine LEZ is built on. Both run as ordinary program code, with no dedicated LEZ precompile to speed them up, so the first question on this project was whether that’s affordable or a problem.

Measuring it is our first deliverable, and the report will cover the cycle costs, how they break down between cryptography and framework overhead, how they scale with signer count, and what a precompile would and wouldn’t buy. That report will be delivered to Logos with a recommendation on whether a precompile is worth building as follow-on work. We’ll publish it alongside the measurement harnesses, so anyone can reproduce the figures rather than take them from us.

We hit a version of this problem on Aleo, where verifying signatures from multiple signers inside a cryptographic circuit cost more than the design could absorb. Our engineers implemented FROST, a threshold signing scheme, from scratch, so the circuit could check one aggregated signature instead. That’s what drew us to this project.

What Kanon won’t do

Pull mode works only for public execution. If you want to supply and verify a price update inside your own transaction, that transaction is visible. Private applications read the shared price that push mode maintains instead.

Kanon reports how old a price is. What that means is your call. A price sitting at the edge of its freshness window is fine for some applications and a reason to stop for others, and the answer depends on what you do with the number. The documentation will cover how to handle stale and unavailable prices, but it won’t make the decision for you.

Divergence between sources works the same way. Applications pairing Kanon with the TWAP feed will sometimes see the two disagree, and deciding which to believe, or treating the gap itself as a stop signal, stays with the application.

Where this is, as of September 2026

Kanon targets LEZ testnet first. The cost measurement is our current milestone; the adaptor, SDK, tooling, and dashboard follow.

Get involved

Once the first components are ready to test, we’d welcome help from Logos contributors. It will be possible to try the dashboard in Basecamp, work through an example, or connect a feed to something you’re building. Tell us where you got stuck, including setup instructions that didn’t make sense and error messages that didn’t say what to do next.

Testing delayed and missing updates is especially useful. An outdated feed should be obvious on the dashboard, and applications need to handle old prices correctly. Once the TWAP feed lands, we’d like to know how the two sources behave together in a real integration. Include steps to reproduce anything unexpected.

You don’t need to wait for a release to talk about an integration. If your Logos project needs price data, comment on our Kanon proposal (or use Discord Builders channels) with the feeds you expect to use and how often you need them, or volunteer there to help with testing. New to Logos? Start with the Builders Hub.

Kanon takes its name from the Greek κανών, a measuring rod: a reference against which other things are measured. A measuring rod is only useful if you can check it yourself.