Fact-check of the appendix additions confirmed every citation is real and
supported. Two corrections applied:
- Match the RedStone Terms of Use quotes to the source casing (sentence case,
not all-caps) and restore the dropped "or discontinuance" clause.
- Soften the "99.9% de-facto benchmark / nothing higher exists" framing, which
rested on a single directional secondary source, to "the closest published
reliability figure the survey could locate." Aligned the same wording across
the RFP Servicing section and the appendix (prose + targets table).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a Servicing hard requirement: the awarded team operates the day-one
RedStone push feeds under an SLA from software readiness through March 2028
(one year past planned mainnet launch), covering uptime/liveness, update
cadence, incident response, reporting, and handover.
Ground the SLA numbers in a new appendix section (Oracle Service Levels and
Feed Update Parameters). Neither Chainlink nor RedStone publishes a numeric
uptime SLA and RedStone's ToU disclaims availability, so targets are
commitments on the awarded team's own operated stack: 99.9% monthly uptime
(ecosystem de-facto benchmark), 0.5% deviation / 1h heartbeat for volatile
crypto/USD pairs (Chainlink ETH/USD reference).
Reconcile the prior software-only framing (Operator-side T&C, Fee structure,
Timeline, Team Profile) with the operating engagement.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Extend RFP-003 from the BTC/XMR/ETH scope to Bitcoin, Monero, and Zcash
transparent. Drop the Ethereum pair (ETH reaches LEZ via wrapping, which
needs no swap counterparty) and add the Zcash transparent pool via
BIP-199-style HTLCs, with shielded swaps out of scope. Allow either
Bitcoin refund construction (pre-signed timelocked tx or Taproot
script-path tapleaf). Set funding to $100k and note the LEZ-side
primitives are present today.
Add two ecosystem-survey appendices with sources:
- btc-xmr-adaptor-swap-primitives.md
- zcash-atomic-swap-primitives.md
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per README formatting instructions (mdformat + mdformat-gfm +
mdformat-frontmatter, config in .mdformat.toml).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Refresh Protocols Considered table from DeFiLlama (snapshot
2026-04-27): V2 ~$970M, V4 ~$720M (~16 chains, was >$1B/17),
Balancer V3 ~$80M post 2025-11 V2 exploit, Curve ~$1.7B,
Raydium ~$1.0B, Orca ~$255M. Replace unsourced ">$300B" Orca
cumulative with "$36B+ all-time" from Orca's own dashboards.
- Soften "over 100 forks" of V2 to a sourced characterisation.
- Clarify V2 protocol fee: UNIfication passed 2025-12-26; LPs
receive 0.25%, protocol takes 0.05% (1/6 of 0.3%).
- Replace "98% gas reduction" round-number claim with the
underlying TSTORE-vs-SSTORE gas costs (100 vs 20,000) per
EIP-1153.
- Tighten section-10 table: V4 has `PoolManager.sync()` for
flash-accounting balance checkpointing (not reserve
reconciliation); previous wording read as "no sync at all".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Remove recoverSurplus() recommendation. F.9 now requires only
permissionless sync(); appendix section 10 describes ecosystem
practice (Uniswap V2 sync/skim, V4/Balancer/Curve alternatives)
without prescribing LEZ behaviour.
- Reframe F.8: the DEX program must be compatible with ATAs but
must not force them. Pool vaults may use PDAs (matching Raydium
and Orca); user-side accepts any valid SPL token account owned
by the caller.
- Restructure appendix to describe what ecosystem DEXes do, not
what LEZ should do. Recommendations belong in the RFP body.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add appendix documenting how existing DEX protocols implement
behaviours required by RFP-004: constant-product AMM, immutable fee
tiers, slippage protection, fee distribution, pool creation, single
transaction operations, pool analytics, ATA usage, and vault
accounting patterns.
Recommend implementing sync() (permissionless) and recoverSurplus()
(restricted to zero-liquidity pools) based on ecosystem analysis.
Add requirement F.9 to RFP-004 referencing the appendix.
Research source: github.com/marclawclaw/research-dex
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
RFP-012 mixed MetaMorpho V1 and Vaults V2 semantics: it mandated V1's
supply-queue/withdraw-queue allocation while also requiring the V2
Sentinel role and citing V2 docs. Target is V2, so:
- Replace supply/withdraw queues with adapter-based allocation
(allocate/deallocate, liquidityAdapter).
- Switch per-market supply caps to ID-based risk caps (absolute and
relative, keyed to collateral/market/protocol) throughout.
- Scope curator/allocator roles to V2 (curator cannot allocate
directly; allocator manages liquidityAdapter and setMaxRate).
- Add forceDeallocate in-kind redemption to the withdrawal model.
- Reword the bad-debt asymmetry note from the queue model to the
adapter model.
- Correct the F9 timelock claim: V2 enforces no minimum timelock
(per-selector, default zero, overflow-bounded max); a sensible LEZ
minimum is an applicant deployment-time choice, not a "24h minimum".
Appendix: document V2 mechanics verbatim from docs.morpho.org and
VaultV2.sol (adapters, ID-based caps, forceDeallocate, timelock,
virtual-offset inflation mitigation, lazy loss realisation), and fix
the summary-table timelock row that incorrectly carried V1's 24h rule.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Appendix:
- Drop V1 MetaMorpho content entirely. The vault deep-dive now
describes Morpho Vaults V2 only: V2 spec table (no V1/V2 comparison),
V2 role semantics (Owner / Curator / Allocator / Sentinel), and a
V2-Sentinel threat-model write-up. Removed the V1-Guardian section
with B.Protocol oSnap and Steakhouse Aragon-DAO patterns (those are
V1-only). Renamed "MetaMorpho" references to "Morpho Vaults V2"
where current.
- Fix Babylon docs URL: docs.babylonchain.io is NXDOMAIN; replace with
the current docs.babylonlabs.io domain.
RFPs:
- RFP-008 and RFP-012 Supportability: add an Audit Programme hard
requirement. The proposal must name at least one tier-1 audit firm,
include the audit budget as a proposal line item, and include the
timeline. Audit reports must be published before any mainnet
recommendation. Removed the prior "audits are out of scope" line
from RFP-008 Out-of-Scope; that framing no longer applies.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- RFP-012 F10: rename Guardian to Sentinel and adopt Morpho Vaults V2
semantics (deallocate, instant cap decrease, revoke pending). Owner
(not curator) appoints. Reference docs.morpho.org/morpho-vaults/concepts/roles.
- RFP-012 R4: make bad-debt accounting "on touch" explicit and document
the queue-order withdrawal asymmetry (informed depositors can exit
before next-touch repricing). Add disclosure requirement.
- RFP-008 F8: cite the Morpho liquidation incentive formula
LIF = min(M, 1/(beta*LLTV + (1-beta))) with beta=0.3, M=1.15.
- RFP-008 F14: flash loans are zero-fee per the deployed Morpho.sol;
drop the admin-configurable fee.
- RFP-008 P2: replace fixed "20 markets" floor with benchmark-driven
target; Morpho runs 200+ markets on Ethereum.
- RFP-008 Privacy U4: document SDK enforcement of single-use
ephemeral accounts (LEZ keypair-derivation makes fresh-history
trivial; preventing reuse is SDK state).
- RFP-008 TVL figures aligned with appendix (Morpho Blue core ~$4.9B,
full stack $11.78B); RFP-012 [DATA NEEDED] resolved with the same
numbers plus Coinbase/Steakhouse multi-billion AUM.
- Appendix V1/V2 roles row corrected: V2 is Sentinel, not "Same".
- [SOURCE NEEDED] on LEZ private-tx-per-block reframed as pending
upstream doc rather than a citation we owe.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Apply the equivalence bundle: singleton + immutable core + bounded
admin scope, AdaptiveCurveIRM as launch IRM, formal verification
promoted to hard, LEZ-native flash loans (tail-call + unforgeable
repayment capability) replacing EVM reentrancy framing, reference
liquidator and risk monitor reframed as fork-and-run software.
Scope clarified: this RFP funds software, mainnet deployment / LLTV
grid / oracle approval / admin governance are out of scope.
Platform deps: add on-chain clock and LP-0013 as hard blockers,
promote LP-0012 (events) from soft to hard, add a liquidation CU
benchmark deliverable. Open question on the off-chain indexer
captured inline with pointer to logos-co/ecosystem#137.
Replace appendix/lending-platform.md with appendix/lending-ecosystem.md
(ecosystem survey only; Logos-specific content stays inline per
CLAUDE.md). Minor edits to RFP-012 carry over from prior session.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- fix broken relative links in appendix (./RFPs -> ../RFPs)
- rename RFP-012 file to match its title (curated-lending-vaults)
- update LP-0015/LP-0012 URLs from main to master branch
- remove on-chain clock blocker (resolved in logos-execution-zone)
- source the Solana compute-budget figures and mark liquidation CU
cost as [BENCHMARK NEEDED]
- add Supportability item for the privacy and anonymisation
properties document, aligning both RFPs with the template
- rewrite promotional and rule-of-three passages in the Overview
and Why This Matters sections
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Rewrite RFP-008 from Aave-style shared pools to Morpho Blue isolated
markets. Extract shared privacy architecture and platform dependencies
into appendix/lending-platform.md. Update RFP-012 from Aave v3 features
to MetaMorpho curated vaults.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Keep RFP-008 and RFP-012 as open per upstream; retain RFP-013 and RFP-014
as draft; include RFP-015 through RFP-017 from master.
Co-authored-by: Cursor <cursoragent@cursor.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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
