rfp: add RFP-019 TWAP oracle and price feed infrastructure by fryorcraken · Pull Request #37 · logos-co/rfp

fryorcraken · 2026-04-07T07:40:27Z

Summary

Splits the original price-feed work into two RFPs and adds the supporting research:

RFP-019 — TWAP oracle and price feed infrastructure (RFPs/RFP-019-twap-oracle.md). Owns the on-chain TWAP tier and the canonical oracle price account standard. Reads LEZ-native AMM pool state (gated on RFP-004), so no external publisher signature is involved.
RFP-020 — RedStone off-chain oracle adaptor (RFPs/RFP-020-redstone-oracle-adaptor.md). Public-mode push aggregator for RedStone-signed data packages, day-one XMR/USD and ZEC/USD coverage, with cost measurement of the in-program RISC-V verification path as a primary deliverable.
Ecosystem research appendix (appendix/oracle-ecosystem.md). Per-scheme analysis of the four adaptor shapes, RedStone vs Pyth comparison, signature-verification cost across host chains, FROST + DLC publisher landscape, privacy-asset feed availability matrix.
Slide deck (appendix/oracle-ift-research-slides.md). Talk-track for RFP-019 + RFP-020, including the LEZ-side cost reframe and the four-shape walkthrough.

Design Rationale highlights

Why two RFPs. The on-chain tier and the off-chain adaptor have different dependency graphs (RFP-019 gates on the DEX, RFP-020 is unblocked today), different security models (DEX liquidity vs M-of-N signers), and different scope; combining them muddied both. Production DeFi layers them, and the canonical price account standard makes the layering swap-out cheap.
Push aggregator with private-account composability. RFP-020's adaptor runs in public-execution mode: signature verification happens once on the write side, private accounts compose by reading the public price account. Pull-mode reads from inside private execution are foreclosed today on consumer CPU (lez-signature-bench measures every scheme well above 30s end-to-end).
Schnorr-exposure benefit is public-mode CU only. A LEZ-side host primitive for BIP-340 Schnorr (or for secp256k1 ECDSA + keccak256 as the cost-conditional follow-on) lowers public-mode write-side compute units but does not unblock private-execution pull: a host function lives outside the ZK proof boundary, so it cannot be called from inside the privacy circuit. To reach private-execution pull, you need either a RISC0 zkVM circuit-level accelerator or a different upstream signature scheme with acceptable in-circuit cost — both deferred to possible separate follow-on RFPs, contingent on consumer-protocol demand which is not yet established.
lez-signature-bench numbers. Cross-scheme RISC0 measurements (CPU-only Ryzen 9 7940HS, no CUDA, no Bonsai): ECDSA P-256 at 4:58 E2E private TX (3-of-N), Schnorr secp256k1 at 5:22, ECDSA secp256k1 at 7:26, Ed25519 at 11:09. None hit sub-30s interactive UX; numbers inform the public-mode aggregator design choice and any future private-mode-friendly upstream follow-on.

Test plan

Reviewer reads RFP-019 and RFP-020 Design Rationale sections end-to-end
Reviewer cross-checks the four-shape framing in the slide deck against the appendix
Reviewer confirms the canonical price account standard in RFP-019 is consumable from RFP-020's push aggregator without ambiguity

Fix logos-co/ecosystem#109

seugu

Thank you for the informative RFP doc!

seugu · 2026-04-09T21:28:32Z

+#### Functionality
+
+1. Implement an on-chain TWAP oracle program that reads pool
+   accumulators from a LEZ DEX (RFP-004) and computes the geometric


computes the geometric mean

I assume that we do not need private computation here all computations can be done by the public executions right? Theregore, everyone can query and use the oracle price in their LEZ Dapps.

Confirmed: oracle programs run as public LEZ executions with no confidential state. All accumulator updates, TWAP computation (including the geometric mean), external feed verification, and price queries are visible to any caller, and any LEZ dapp can read the same canonical price. I have added a "Public oracle execution" subsection to the Design Rationale to make this explicit. Confidential execution is reserved for application-layer protocols that consume oracle prices (e.g. private DEX swaps in RFP-004); the price feed itself stays public.

seugu · 2026-04-10T00:09:04Z

+3. Provide a query interface: given a pool address and a window
+   length, return the TWAP price and the observation timestamps
+   used.
+4. Implement an external oracle adaptor for Pyth: verify Wormhole


I understand that Wormhole verification requires 13 many ECDSA sig verification (one by one) over secpk256 curve from this and this which looks doable in LEZ due to its native curve, only it requres to implement ECDSA.

Confirmed against primary sources. The new "Signature Verification Schemes" appendix section documents this in detail: 19 guardians, 13-of-19 quorum, plain ECDSA over secp256k1 (no aggregation). LEZ inherits Solana's native secp256k1 SigVerify precompile, so VAA verification is feasible without new opcodes; the precompile is invoked in batches of 6-7 due to per-instruction CU limits (approximately 6,690 CU per signature, so ~87K CU for the full 13-sig set, plus the Merkle proof). Pyth's Perseus upgrade amortises this across multiple feeds for a 50-80% reduction. ZK alternatives (Boundless / RISC Zero) exist for some flows on Ethereum / L2 but are not used by Pyth in production.

seugu · 2026-04-10T00:24:52Z

+
+**RedStone.** Modular oracle with both push and pull delivery. Pull
+model attaches signed data to EVM calldata; the on-chain contract
+verifies node signatures without requiring a bridge or dedicated


for redstone verification, I think they have different sig types for chains e.g. for EVM its ECDSA over the secp256k1, while for steallar they use curve25519 ref. We can choose the optimum type among these for LEZ.

Investigated against primary sources and the picture is a bit different from what the link suggests. RedStone uses the same signing scheme on every chain it serves: secp256k1 + keccak256 (Ethereum-style ECDSA) data packages. The Ed25519-curve reference in DeployingFeed.md is about the Stellar deployer account key (Stellar's native account model is ed25519), not about RedStone's data-package signature scheme. Confirmed via the rust-sdk Cargo.toml (depends on secp256k1 and k256 with sha3, no ed25519), the EVM connector (uses ecrecover on keccak256), and the Veridise audit of the Soroban Stellar contract (describes ECDSA validation). Each chain connector recovers the same ECDSA signatures using whatever host primitive is available; on Stellar that is CAP-0051's recover_key_ecdsa_secp256k1 (~2.3M CPU instructions). Implication for LEZ: no per-chain optimum to pick; LEZ inherits Solana's secp256k1 precompile and can verify RedStone's M-of-N data packages directly (approximately 20K to 35K CU for 3-of-N), making RedStone the simpler day-one integration. New "RedStone per-chain signatures" subsection in the appendix documents this with citations.

Thank you, this is better.

seugu · 2026-04-10T00:26:39Z

+
+This appendix surveys oracle protocols, TWAP mechanics, manipulation
+vectors, and external oracle models relevant to
+[RFP-019](../RFPs/RFP-019-twap-oracle.md). It provides the technical


Semantic Line Breaks is not applied here right?

sembr makes it difficult to read raw documents, so I usually dont apply it when it's not a protocol spec or something else that needs hard tracking.

Clarify that oracle programs run as public LEZ executions (per seugu review). Add Signature Verification Schemes appendix section documenting the Wormhole VAA scheme (13-of-19 ECDSA secp256k1) and RedStone's per-chain signature reality (secp256k1 + keccak256 everywhere; the Stellar Ed25519 reference is the deployer account key, not the data package scheme). Refresh stale Q1 2026 figures: Chainlink TVS, Pyth chain/feed/publisher counts, Chronicle and RedStone TVS. Correct Compound V3 description (zero-value validation only, not bounds-checking circuit breaker) and re-cite the Pyth incident list. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

fryorcraken · 2026-05-01T07:08:04Z

Appendix and RFP-19 ready to review

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Clarify that oracle programs run as public LEZ executions (per seugu review). Add Signature Verification Schemes appendix section documenting the Wormhole VAA scheme (13-of-19 ECDSA secp256k1) and RedStone's per-chain signature reality (secp256k1 + keccak256 everywhere; the Stellar Ed25519 reference is the deployer account key, not the data package scheme). Refresh stale Q1 2026 figures: Chainlink TVS, Pyth chain/feed/publisher counts, Chronicle and RedStone TVS. Correct Compound V3 description (zero-value validation only, not bounds-checking circuit breaker) and re-cite the Pyth incident list. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Document XMR/USD and ZEC/USD coverage across surveyed oracles (Chainlink push and Data Streams, Pyth, RedStone, DIA, Supra, Chronicle, API3, Switchboard) with self-serve-on-LEZ assessment for each. Pure factual content; no recommendations. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Narrow RFP-019 to the on-chain TWAP tier only (TWAP program, canonical oracle price account standard, circuit-breaker interface). Move the external oracle adaptor work into a dedicated RFP-020 for RedStone, motivated by enabling private DeFi via day-one XMR/USD and ZEC/USD feeds on LEZ. Pyth is deferred to a future RFP since it depends on Wormhole on LEZ. RFP-020 references the canonical standard from RFP-019 and frames the LSC stablecoin Path A vs Path B choice as a business decision left to the RFP-013 implementer. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Match the section structure used in RFP-015/RFP-016 (Design Rationale with emoji header) and RFP-008/RFP-012 (Out of Scope section). Drop the non-standard Evaluation Criteria section and extend Supportability with the standard doc-packet and Figma requirements that live RFPs use. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Drop the AI-tell vocabulary ("robust" twice; "the clearest day-one differentiator and the most direct path"; "informed by the realities of") and recast trailing participles ("reducing reliance on any one source") as direct statements. No content changes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

RFP-020 now implements secp256k1 ECDSA + keccak256 verification as RISC-V program code inside RISC0 on day one; a precompile is a cost-conditional follow-on, not a hard prerequisite. Cost measurement of the in-program path is a primary deliverable. Appendix expanded to reflect the actual LEZ runtime (RISC-V zkVM on RISC0; BIP-340 wired as the transaction-witness primitive only, not exposed to guest programs) and restructured around four adaptor shapes: A trusted re-signer (rejected), B FROST federation (conditional on Schnorr verification for guest programs), C DLC oracles (better fit for prediction markets; same conditional), D secp256k1 ECDSA on LEZ, with D split into D1 (in-program, day 1) and D2 (precompile, cost-conditional follow-on). Adds per-publisher state-of-play for the BIP-340 oracle ecosystem, the dlcspecs plain-SHA-256 vs tagged-SHA-256 split between rust-dlc and Kormir lineages, iBTC federation correction (10-of-15 on iBTC, 7-of-10 on CBTC; FROST live only on the Bitcoin spend path), a Uniswap v4 hook note in the v3 accumulator section, and references [45]-[60] for FROST tooling and DLC oracle infrastructure. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ixes, prose pass RFP-019 Design Rationale gains a "What the production record actually shows" subsection under Circuit-breaker interface, quoting four documented saves (Curve / Vyper July 2023, USDe Binance flash October 2025, MakerDAO OSM March 2025, Base sequencer August 2025) and the counter-evidence (Compound V3 walked away from the TWAP anchor; Aave removed PriceOracleSentinel in v3.7 with no documented saves; Aave CAPO wstETH glitch March 2026). Closes with the load-bearing-layer-is-source-diversification framing and an instruction that the Recommended Consumer Pattern should treat divergence-flag cross-check as a guard rail, not a primary defence. RFP-019 + RFP-020 Usability + Supportability gain explicit requirements for a reference consumer program and a "Recommended Consumer Pattern" section in the SDK doc packet. RFP-019 soft requirements rewritten: dropped the median-aggregation, Ormer, and historical-API items (each contradicted the design or duplicated existing functionality); replaced with a single aggregator-helper SDK utility item. Appendix fact-check fixes: Pyth feed-count drift between tables resolved (1,500+ -> 2,800+); Chainlink and Chronicle TVS rows date-stamped against Q1 2026 reporting; Switchboard / Supra rows gain DefiLlama citation; comparison-table Chainlink RPC cell updated to match the corrected prose; "Self-serve on LEZ" RedStone cell tightened to make the shape D dependency explicit; Liquity V2 "explicitly rejects" softened to "explicitly prefers"; numeric DLC "cent granularity" framing tightened against base-2 precision math; ChainSecurity reference URL updated to canonical form. Both RFPs run through the humanize-prose skill: removed intensifier and promotional-tone clusters from the Overview / Why This Matters / LEZ-data-standard sections; replaced prose em-dashes with colons; spelling normalised to Australian English. Heading-construction em-dashes preserved per project convention. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…mer-pays push variant The LEZ public / private execution split enables a freshness pattern that doesn't apply to other chains: a user who needs a fresh price can submit a public transaction that pushes a signed payload to the aggregator account, then submit a private transaction immediately after that reads the just-updated price. Verification cost is paid in the public path (cheaper, especially under the precompile follow-on); the private path does no signature work. This recovers pull mode's "fresh at transaction time" property for private consumers without paying in-circuit verification cost in the privacy proof. The same mechanism enables a consumer-pays push variant that does not require a dedicated relayer: users push when they need a fresh price, idle periods incur zero update cost, the aggregator only advances when someone needs it. Operationally pull, structurally push. Heartbeat relayer (RedStone's own pusher or a sovereign one) and consumer-pays push can coexist; the program logic does not distinguish between them. Documented in the appendix's "Push mode is preferable to pull mode on LEZ" subsection and mirrored in RFP-020's public-mode-aggregator design rationale. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…data Early prototype work on in-program secp256k1 ECDSA inside RISC0 (`fryorcraken/lez-ecdsa`) puts proof generation in the order of minutes on consumer hardware. That is enough to rule out private-execution pull mode in practice, absent a RISC0-specific signature-verification accelerator. The framing across the Overview, the Public-mode-aggregator subsection, the RISC-V verification path subsection, and the appendix shape D body now reflects this: - Private-execution pull mode is treated as out of reach, not as "expensive but possible". - Cost measurement remains a primary deliverable, but scoped to the public-mode write side, where amortisation across all downstream reads can make a per-update cost workable that would be unworkable per-private-transaction. - The escape hatch is explicit: a RISC0-specific signature- verification accelerator (e.g. a future risc0-ecdsa extension or a secp256k1 precompile in the zkVM proving system itself) could change the picture; until one lands, treat the result as fixed. The push-mode design is the working assumption, not a contingent choice; the precompile follow-on is closer to expected than conditional. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Convert the bare `fryorcraken/lez-ecdsa` references to proper markdown links pointing at https://github.com/fryorcraken/lez-ecdsa so a reader can click through to the prototype. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The (Scope note: ... unrelated to the RLN service-attestation oracle work on the anon-comms roadmap.) parenthetical assumes the reader knows what RLN is. For a reader who doesn't, it adds noise without saving them from a real misread risk. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The "Logos's thesis is private DeFi" line was internal-strategy language. The relevant motivation for an external builder is that LEZ is positioned to support private DeFi, that USD reference prices for XMR and ZEC are a necessary step, and that downstream RFPs (RFP-013 stablecoin, RFP-004 DEX, wrapped privacy assets) depend on those prices. Rewritten accordingly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Replace the bare "without an off-chain oracle adaptor, none of these applications can ship" closer with the substance: TWAP is not sufficient on its own at LEZ launch (linear-with-depth manipulation cost on thin pools, plus the structural fact that XMR/USD and ZEC/USD have no on-chain pools to TWAP from), so an off-chain feed is the only way to get the day-one prices on chain. Pairs the TWAP-and-off-chain layered defence framing in the appendix and RFP-019. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Replace the Path A vs Path B decomposition (LSC-specific) with a shorter "building blocks, not a production-grade design" framing. Acknowledges that neither off-chain nor on-chain TWAP is a complete oracle on its own and that the production norm is layering, then notes that consuming protocols compose the pieces according to their own production-security choices. The canonical price account standard from RFP-019 keeps swap-out cheap if those choices change later. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous heading misread as if the deliverable itself were not production-grade. The point is the opposite: this RFP delivers production-grade code for one building block in a layered oracle stack. Renamed to "A building block in a layered oracle stack" and added an explicit "production-grade code on its own terms" clause in the body. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…al-disclosed sigs The previous text introduced the consumer-pays push variant without distinguishing it from the rejected "put the signature in the journal" option. That risked reading as if the same privacy concern applied. Add an explicit clarification in both the appendix and RFP-020: - Two-transaction split: signature lives in the public push transaction only; the private transaction reads the public price account by address with no upstream signature in its body. Private transaction's contents (assets, counterparty, amount) stay private. - Fits the existing adaptor write path: the program already accepts signed payloads from any caller; consumer-pays push exercises that path from an end-user wallet rather than from a dedicated relayer. No new program logic. - Residual linkability risk: an observer can correlate a public push from wallet X at time T with a private transaction at time T+epsilon and infer the same actor consumes the just-pushed price. Mitigations (separate funding wallet for the push, timing decorrelation, heartbeat masking) are consumer-side production-security choices, not adaptor-side guarantees. Privacy story is strictly better than journal-disclosed signatures, not equivalent to a heartbeat-only push model. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The "D1" / "D2" labels are appendix internals (Path D1 = in-program, Path D2 = precompile follow-on, under shape D in the four-shape analysis). A reader of RFP-020 hasn't necessarily read the appendix and won't know what D1 means. Replace the stray "under D1" in the RISC-V verification path subsection with "for the in-program path", which matches the descriptive labels used elsewhere in the RFP. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- Resolve fee-structure TODO: stop prescribing a fee model; structural pull-oracle observation kept, downstream users decide policy. - Resolve relayer-daemon TODO: add Usability #4 covering a relayer daemon (configurable feeds/cadence, retry/back-off, structured logging, clean shutdown); renumber subsequent Usability items. - Lift scope-limit clauses out of the Overview prose into a dedicated Scope subsection (in scope / out of scope at Overview level). - Cross-link the appendix's "Implications for LEZ" four-shape analysis from the public-mode aggregator design rationale. - Update prototype repo URL fryorcraken/lez-ecdsa -> fryorcraken/lez-signature-bench in RFP-020 (2 refs) and appendix (2 refs). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous wording ("Because RedStone is a pull oracle, the cost of an update naturally falls on whoever submits the signed data package on-chain") was inherited from RedStone's native pull model and contradicted the push-aggregator shape this RFP commits to. Rename the subsection to "Fee structure" and explain the amortised single-write cost model with the relayer as the entity that pays in practice. The non-prescriptive policy paragraph is preserved. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…scheme Today the in-program ECDSA path forecloses pull-mode reads from private execution (proving cost in the order of minutes). The public-mode precompile follow-on does not unlock that case either: a precompile lives outside the ZK proof boundary, so it cannot be called from inside a private transaction. Add an explicit note that if a signature scheme exists or can be selected with acceptable in-circuit cost on RISC0, modifying an existing oracle network to publish in that scheme (or standing up a new publisher set that does) is the subject of a possible separate follow-on RFP. Updated: - Overview Scope subsection: pull-mode-from-private bullet now enumerates all three blockers and the two distinct follow-on RFP shapes. - Design Rationale "RISC-V verification path and the precompile question": new paragraph after the localised-swap note. - Out of Scope section: new explicit non-goal bullet for the alternative-signature-scheme path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Note that the value of any follow-on aimed at unlocking pull-mode reads from inside private execution depends on consumer-protocol demand that has not yet been established. Cite RFP-013's LSC stablecoin as an example of a consumer that already constrains specific actions to public transactions for its own design reasons. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Replace "in the order of minutes" hand-waves with the four-scheme CPU bench: ECDSA secp256k1 at 3-of-N is 7:26 E2E (4:20 local prove); cross-scheme ranking adds P-256 and Schnorr as cheaper candidates for a future private-mode-friendly upstream. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The bench measures proving cost (private-execution path). The public-mode aggregator does no proving, so its write-side cost is in LEZ compute units, not proof time, and is not captured by the bench. Updated three places that conflated local-prove with public-mode aggregator cost. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ic-mode CU only Tightens the framing around "LEZ exposing BIP-340 Schnorr verification to guest programs" so the benefit is stated explicitly: lower public-mode compute-unit cost on the aggregator write side (analogous to shape D's ECDSA precompile follow-on, with a smaller engineering ask since the runtime primitive already exists). It does not unblock private-execution pull, because a host function lives outside the ZK proof boundary and so cannot be called from inside the privacy circuit (the same D2 structural argument that forecloses private pull under an ECDSA precompile). Also fixes RFP-020's out-of-scope bullet, which previously listed a LEZ secp256k1 + keccak256 precompile alongside a RISC0 zkVM accelerator as possible unblockers for private-execution pull. Only the latter (or a different upstream signature scheme with cheap in-circuit cost) actually reaches private execution; the precompile is public-mode only. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Shape B was previously framed as a federation that signs the *data*, with the program verifying the FROST-aggregated BIP-340 signature in-circuit. That framing put B's cost question at parity with shape D and made B contingent on LEZ exposing Schnorr verification to guest programs. Replace with FROST tx-signing: the federation jointly FROST-signs the LEZ transaction itself, emitting one BIP-340 signature as the tx witness. Since FROST output is byte-identical to a single BIP-340 signature under the aggregate pubkey, the runtime's existing tx-admission BIP-340 primitive should validate it without changes. Under that PoC assumption, the federation's write tx pays only standard tx-admission verification (host program, outside the RISC-V zkVM circuit), with no in-program signature verification by the aggregator program; public-mode push CU is therefore lower than D. If the assumption fails, the federation falls back to in-program data-sig verification at the bench's in-circuit Schnorr cost. Either way, shape B is push-only mode. It does not unlock private-execution pull: shape B authenticates a write transaction submitted by the federation, while private pull would require the consumer's own private tx to authenticate the upstream data inside its own ZK circuit. Private consumers read the public price account the federation writes, identical to push-mode reads under shape D. Updates to keep the surrounding analysis consistent: the four-shapes framing now groups A and B as runtime-handled tx-witness shapes (in-circuit cost question only arises in C and D); shape C's "same runtime dependency as shape B" cross-reference is changed to "same in-circuit cost question as shape D"; the slides' four-shapes table, walk-through prose, and two Q&A entries (FROST, BIP-340-at-oracle) are aligned with the new framing. Also includes pre-existing slides edits the user had staged locally: TWAP-vs-off-chain table formatting and a "What RFPs are for?" slide rewrite with a funding-models table. Supersedes 141611f, which had hardened the previous data-signing framing instead of replacing it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

seugu · 2026-05-05T10:01:29Z

+array of up to 65,535 slots, expandable via
+`increaseObservationCardinalityNext()` at a one-time gas cost [9].
+
+Note on Uniswap v4: v4 removed the oracle from core pool state and


Maybe we can also mention here Uniswap v4 adopts the TWAP with truncated price which means TWAP only allows limited price updates not more for a better protection. Because v3 TWAP must be still vulnerable. ref

fryorcraken · 2026-05-06T12:02:25Z

Only XMR/ZEC feed is actually needed, no plan to have USD on chain.
Need to investigate uniswap v4 rfp: add RFP-019 TWAP oracle and price feed infrastructure #37 (comment)
Could there be an attack that purposefully engage the circuit-breaker (via TWAP manipulation)
Dig into the infrastructure needs for RedStone and Pyth

fryorcraken changed the title ~~rfp: add RFP-018 TWAP oracle and price feed infrastructure~~ rfp: add RFP-019 TWAP oracle and price feed infrastructure Apr 8, 2026

seugu reviewed Apr 10, 2026

View reviewed changes

fryorcraken force-pushed the rfp/twap-oracle branch from fc1617f to 4192b18 Compare April 28, 2026 10:30

fryorcraken force-pushed the rfp/twap-oracle branch from de71691 to 3fc7ebb Compare May 4, 2026 03:13

fryorcraken marked this pull request as ready for review May 4, 2026 06:30

fryorcraken and others added 22 commits May 4, 2026 16:31

rfp: add RFP-018 TWAP oracle and price feed infrastructure

897aacd

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add appendix

046379f

add link

88bc83e

Add some TODOs

a01fea2

fryorcraken and others added 2 commits May 4, 2026 16:32

fryorcraken force-pushed the rfp/twap-oracle branch from 6cf638b to 0c70476 Compare May 5, 2026 00:18

fryorcraken and others added 8 commits May 5, 2026 13:40

appendix: add RFP-019 + RFP-020 slide deck and fact-check

265287f

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

appendix: rename slide files to oracle-ift-research-slides

d4ef9e0

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

appendix: remove slide fact-check (addressed)

40a8346

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

seugu reviewed May 5, 2026

View reviewed changes

fryorcraken added 3 commits May 6, 2026 12:23

TODO day 1 feeds

72f5e50

slide pass

624239a

other chains and events

1f0e133

fryorcraken added 2 commits May 6, 2026 22:05

clarifying frost

f6c3aa2

uniswap v4

4d666c1

Conversation

fryorcraken commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Design Rationale highlights

Test plan

Uh oh!

seugu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fryorcraken commented May 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fryorcraken commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fryorcraken commented Apr 7, 2026 •

edited

Loading

fryorcraken commented May 6, 2026 •

edited

Loading