diff --git a/.github/ISSUE_TEMPLATE/proposal.yml b/.github/ISSUE_TEMPLATE/proposal.yml index 44172d4d..eb59bedb 100644 --- a/.github/ISSUE_TEMPLATE/proposal.yml +++ b/.github/ISSUE_TEMPLATE/proposal.yml @@ -14,6 +14,8 @@ body: - "RFP-015 — Token Launchpad: Bonding Curve" - "RFP-016 — Token Launchpad: LBP" - "RFP-017 — Privacy-Preserving Token Vesting" + - "RFP-021 — Trustless Ethereum State Attestation for LEZ" + - "RFP-022 — Privacy-Preserving Wrapped ERC-20 and Ether Bridge for LEZ" validations: required: true diff --git a/README.md b/README.md index 9de0cd9f..ffb81f0e 100644 --- a/README.md +++ b/README.md @@ -74,21 +74,23 @@ Click an RFP to view details. Use the Submit Proposal button to apply. -| ID | Title | Tier | Status | Submission Deadline | Category | Submit Proposal | -| ------- | ------------------------------------------------------------------------------------ | ---- | ------ | ------------------- | ---------------------------------- | ----------------------------------------------------------------------------------- | -| RFP-001 | [Admin Authority Library](RFPs/RFP-001-admin-authority-lib.md) | XS | closed | - | Developer Tooling & Infrastructure | Closed | -| RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | closed | - | Developer Tooling & Infrastructure | Closed | -| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | closed | - | Applications & Integrations | Closed | -| RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | closed | - | Applications & Integrations | Closed | -| RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | closed | - | Applications & Integrations | Closed | -| RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | closed | - | Applications & Integrations | Reopening soon | -| RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | closed | - | Applications & Integrations | Closed | -| RFP-014 | [Liquidation & Auction Engine](RFPs/RFP-014-liquidation-auction-engine.md) | L | closed | - | Applications & Integrations | Reopening soon | -| RFP-015 | [Token Launchpad: Bonding Curve](RFPs/RFP-015-bonding-curve-launchpad.md) | L | open | 01/09/26 | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | open | 01/09/26 | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | open | 09/09/26 | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-019 | [On-Chain TWAP Oracle](RFPs/RFP-019-twap-oracle.md) | L | closed | - | Developer Tooling & Infrastructure | Closed | -| RFP-020 | [RedStone Off-Chain Oracle Adaptor for LEZ](RFPs/RFP-020-redstone-oracle-adaptor.md) | M | closed | - | Developer Tooling & Infrastructure | Closed | +| ID | Title | Tier | Status | Submission Deadline | Category | Submit Proposal | +| ------- | ------------------------------------------------------------------------------------------- | ---- | ------ | ------------------- | ---------------------------------- | ----------------------------------------------------------------------------------- | +| RFP-001 | [Admin Authority Library](RFPs/RFP-001-admin-authority-lib.md) | XS | closed | - | Developer Tooling & Infrastructure | Closed | +| RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | closed | - | Developer Tooling & Infrastructure | Closed | +| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | closed | - | Applications & Integrations | Closed | +| RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | closed | - | Applications & Integrations | Closed | +| RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | closed | - | Applications & Integrations | Closed | +| RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | closed | - | Applications & Integrations | Reopening soon | +| RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | closed | - | Applications & Integrations | Closed | +| RFP-014 | [Liquidation & Auction Engine](RFPs/RFP-014-liquidation-auction-engine.md) | L | closed | - | Applications & Integrations | Reopening soon | +| RFP-015 | [Token Launchpad: Bonding Curve](RFPs/RFP-015-bonding-curve-launchpad.md) | L | open | 01/09/26 | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | open | 01/09/26 | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | open | 09/09/26 | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-019 | [On-Chain TWAP Oracle](RFPs/RFP-019-twap-oracle.md) | L | closed | - | Developer Tooling & Infrastructure | Closed | +| RFP-020 | [RedStone Off-Chain Oracle Adaptor for LEZ](RFPs/RFP-020-redstone-oracle-adaptor.md) | M | closed | - | Developer Tooling & Infrastructure | Closed | +| RFP-021 | [Trustless Ethereum State Attestation for LEZ](RFPs/RFP-021-ethereum-state-attestation.md) | M | open | - | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-022 | [Privacy-Preserving Wrapped ERC-20 and Ether Bridge for LEZ](RFPs/RFP-022-wrapped-erc20.md) | L | open | - | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | diff --git a/RFPs/RFP-021-ethereum-state-attestation.md b/RFPs/RFP-021-ethereum-state-attestation.md new file mode 100644 index 00000000..4bc48a1b --- /dev/null +++ b/RFPs/RFP-021-ethereum-state-attestation.md @@ -0,0 +1,806 @@ +--- +id: RFP-021 +title: Trustless Ethereum State Attestation for LEZ +tier: M +status: open +category: Developer Tooling & Infrastructure +dependencies: + - id: LP-0012 + reason: Structured on-chain events let clients and off-chain components follow committee handoffs and attestation submissions without polling every account. +--- + + + +# RFP-021 — Trustless Ethereum State Attestation for LEZ + +> **Note.** This specification describes an outcome that may benefit the Logos +> ecosystem. It is a proposal rather than an instruction. Its requirements +> reflect the technical compatibility with the Logos technology stack and are +> the criteria against which proposals and milestones are evaluated. Logos makes +> no representation as to the legal or regulatory treatment of this +> specification or any implementation of it in any jurisdiction. +> +> Teams implementing it are solely responsible for (i) assessing the risks and +> implications of what they build; (ii) obtaining their own professional advice; +> and (iii) for complying with any legal and regulatory requirements that apply +> to them. Software developed under the Program is published and maintained by +> its developers, not by Logos. +> +> Anyone who chooses to deploy, host, operate or use software developed under +> the Program, whether or not they were awarded a grant under the Program, does +> so at their own risk and is solely responsible for complying with any legal or +> regulatory requirements that apply to them. See the +> [Terms & Conditions](../TERMS_AND_CONDITIONS.md). +> +> Deploying the software described in this RFP, operating any service based on +> it, or carrying on business through it may amount to regulated activity in +> some jurisdictions, including where it involves holding or managing users' +> assets or providing services to others. Whoever conducts any such activity +> does so as principal, in their own name, and is solely responsible for +> assessing its regulatory treatment, including any licensing, registration, +> sanctions or anti-money laundering obligations that may apply to them. Logos +> does not make any representation, provides any advice or assumes any +> responsibility in respect of any such determination or compliance. + +## 🧭 Overview + +Build a reusable LEZ primitive that lets any LEZ program act on a fact about +Ethereum state and know that fact is true, with no trusted intermediary. + +A LEZ execution is self-contained: a program reads inputs from LEZ accounts and +instruction data, and its correctness is established **given those inputs**. +Whether an input is a true statement about the outside world is not something +that execution establishes. A program that mints against "a deposit of amount X +occurred on Ethereum" establishes only that it minted given the claim; the claim +itself is uncertified, and whoever controls the input can assert a deposit that +never happened. + +This RFP delivers the missing piece: a LEZ module that verifies Ethereum +consensus and finality, verifies inclusion of a referenced piece of state under +a finalised Ethereum header, evaluates a predicate over that state, and emits a +**verified statement** with no application action attached. It takes an Ethereum +header, the consensus material needed to prove that header is finalised, the +proofs binding the referenced state to that header, and a predicate to check. It +returns a proven assertion that any LEZ program can consume. + +The deliverable is deliberately application-free. Minting, escrow release, +settlement, and every other action belong to the consuming program. This RFP +delivers only the attestation, plus the tooling and documentation a consumer +needs to integrate it. + +Teams will need experience with Ethereum consensus, the light-client and +verified proxy protocols, and LEZ program development. + +## 🔥 Why This Matters + +Every LEZ program that wants to react to something that happened on Ethereum +faces the same problem, and today each would have to solve it independently. +Three workstreams already need it, and they need the same thing: + +- **The wrapped-token bridge** ([RFP-022](./RFP-022-wrapped-erc20.md)). An + Ethereum vault escrows an ERC-20 or native ETH and a LEZ program mints a + canonical wrapped representation. Minting must happen only against a real, + finalised deposit, with no signer or federation trusted to attest to it. That + is a verified deposit statement feeding a mint. RFP-022 already requires + trustless verification of Ethereum consensus and state rather than an + inclusion check alone; this RFP is where that verification is specified and + built. +- **Private cross-chain swaps.** A cross-chain swap that settles on the users' + home chains, with no liquidity resting on LEZ, needs LEZ to confirm that both + legs deposited before it authorises release. Confirming the Ethereum leg is a + verified escrow statement, with no mint and no wrapped asset created. This is + the read-only consumer, using the same attestation with no minting action + attached. +- **The native gas token bridge** ([RFP-023](./RFP-023-gas-token-bridge.md)). + The reverse-direction counterpart to RFP-022, in which LEZ is the vault and + Ethereum the minter. Releasing native gas token from the LEZ vault requires + proof that the corresponding ERC-20 was really burned on Ethereum, which is + another verified statement over finalised Ethereum state, consumed by a + program doing something different again with it. + +These consumers do different things with the statement and carry different trust +and compliance surfaces, but they rely on the same attestation. That is the case +for building it once, as a shared primitive with a single audited verification +path, rather than separately inside each application. It also means the hardest +and most security-critical part of a cross-chain design (consensus verification) +gets one audit, one test suite, and one set of documented trust assumptions, +instead of one per consumer. + +Building it once has a second consequence worth stating: it lowers the barrier +for any future LEZ program that wants to read Ethereum. Cross-chain lending +collateral checks, governance actions mirrored from an Ethereum DAO, proof of +holding an Ethereum-side asset, and airdrop eligibility derived from historic +Ethereum state all reduce to "evaluate a predicate over finalised Ethereum +state", which is exactly what this primitive returns. + +## 🏗 Design Rationale + +### Why an inclusion proof alone is not enough + +The tempting shortcut is to verify an inclusion proof: supply a state root or +block header along with a Merkle path showing the state is included under that +root, and check the path inside the zkVM. That step is necessary and it is not +sufficient. + +Given a chosen state, anyone can construct a header and a set of Merkle paths +that are internally consistent with it. An inclusion proof verifies that a leaf +is included under a **supplied** root. Whether that supplied root is the root of +the real Ethereum chain stays unchecked. A party free to choose the root can +fabricate a self-consistent state in which any deposit they like appears to +exist, generate a valid inclusion proof against it, and pass verification. The +verification will pass. It will have checked a real inclusion proof against a +fabricated Ethereum. + +The missing ingredient is an anchor to canonical Ethereum. Verification has to +establish that the header it reasons about is a header the Ethereum network +agreed on, before any inclusion check against it carries meaning. + +### The anchor: Ethereum finality via the sync committee + +The anchor comes from Ethereum finality. Under proof of stake, Ethereum +finalises checkpoints: once a checkpoint is justified and then finalised, +roughly two epochs after a block, reverting it requires a consensus failure +severe enough to slash at least a third of all staked ETH. The light-client +protocol exposes this through finality updates, and a sync committee of 512 +validators, rotating every sync-committee period, signs headers so a light +client can follow the finalised chain by checking committee signatures. The +beacon state holds `current_sync_committee` and `next_sync_committee`, so the +next committee is known a period ahead and handoffs can be followed forward. A +party tracking the sync committee can confirm that a given header is a finalised +header of the canonical chain without running a full node. + +An attestation therefore establishes three things, in this order: + +1. **Finality.** The supplied Ethereum header belongs to the finalised set, + verified against sync-committee signatures over the light-client finality + update. This is the basis the inclusion step depends on. +2. **Inclusion.** The referenced state or event (a deposit, a contract storage + slot, a log) is included under that finalised header's state or receipts + root, verified by Merkle proof. +3. **Predicate.** A statement over that verified state holds, for example + "contract C holds an escrow of amount X in token T". + +The output is a compact, proven assertion that the predicate holds of finalised +Ethereum state, carrying no trust in whoever supplied the inputs. A dishonest +submitter cannot forge it, since the module checks the sync-committee signature +itself and forging one would require signatures from two thirds of the +committee. A dishonest submitter can only decline to supply update material, +which is why supplying it must be a liveness role rather than a trust role: no +single party may be able to turn a refusal into a block on an honest user. + +### Where the tracking state lives: the permissionless submitter + +Two costs sit inside an attestation and they are not alike. Establishing that a +header is finalised requires BLS12-381 aggregate signature verification over +sync-committee signatures plus verification of committee handoffs, and it is +expensive. Establishing that a piece of state is included under that header is +Merkle-Patricia path verification, and it is cheap. Header finality is also a +fact every consumer needs and no consumer needs privately, whereas inclusion is +specific to the consumer's own transaction. + +The expected design follows that asymmetry. A **light client runs inside the LEZ +program itself**: a submitter supplies light-client update material fetched from +an Ethereum consensus endpoint, the module verifies the sync-committee signature +and the committee handoff, and a module account accumulates the verified +committee and finalised header roots. A **consumer** then submits only an +inclusion proof against a header already verified in that shared state, +performing no signature verification of its own. + +**Submission must be permissionless.** Anyone can spend the gas and advance the +state; no party is designated, and none can be excluded. The submitter is +untrusted because the module verifies the update: it cannot insert a header the +sync committee did not sign, since doing so would require forging signatures +from two thirds of the committee. It can only stop, which is a liveness failure +repaired by anyone else running the same software. Nothing about the role +requires the submitter to be an Ethereum validator or to have any standing on +Ethereum; it needs only access to a consensus endpoint and LEZ gas. + +Permissionless submission creates a coordination problem worth designing for. If +every operator submits the moment an update becomes available, the party with +the lowest latency wins every race and pays for every update, while the others +pay for rejected transactions and get the result for free. The rational response +is to stop running one, and the role collapses precisely because it is contested +and unrewarded. The submitting component therefore has to check whether an +update is still needed before spending gas on it, and vary its timing so the +cost lands on different operators across updates rather than always the same +one. + +Nobody is obliged to submit updates, and the design does not pretend otherwise. +What makes the role viable is that one submission serves every consumer reading +the resulting header, so the cost is paid once per period rather than once per +attestation, and the protocols whose users depend on fresh headers are motivated +to keep them fresh. The guarantee is not that a submitter will always act; it is +that a stalled instance can be advanced by any party willing to pay, without +permission and without any prior relationship to it. The failure mode is delay, +not loss. + +Trust enters once, when an instance is initialised, through the +weak-subjectivity checkpoint. That input is independently verifiable against +public Ethereum history, which is why Functionality #9 requires that +verification be exposed as an API on the Logos Ethereum core module rather than +left as a configured value. And it is recoverable: nothing prevents initialising +a second instance with a corrected checkpoint, so a failed bootstrap is repaired +by initialising again rather than by a privileged party mutating the existing +one. + +The counterweight is that fragmenting across instances splits the operator +incentive, duplicates gas, and forces every consumer to choose which instance to +trust, dissolving the shared-state benefit that motivates the architecture. A +single canonical instance per chain, which consumers converge on, is the +intended outcome, and a replacement instance is a recovery path rather than a +routine one. + +Sync-committee tracking itself is established rather than novel, and has been +built and audited several times over: Telepathy, SP1 Helios, and `r0vm-helios` +all implement it, audited by Veridise, Zellic, and zkSecurity respectively. +Those systems target destination chains that cannot verify a sync-committee +signature affordably, so they prove the check off-chain and verify a succinct +proof on the destination. What transfers here is their light-client logic, which +an applicant should assess for reuse per the Design Rationale note below. The +[Ethereum Light Client Ecosystem appendix](../appendix/ethereum-light-client-ecosystem.md) +surveys these implementations, their trust models, and a production fork that +deliberately made submission permissioned, which is direct evidence that +permissionlessness is a design choice rather than a property these systems +confer automatically. + +### Trust assumptions the design carries + +The anchor is not free of assumptions, and both must be documented for consumers +rather than buried: + +- **Honest sync-committee supermajority.** Following the chain through committee + signatures trusts that at least two thirds of the current 512-validator sync + committee are honest. This is weaker than Ethereum's full economic finality: a + committee that colludes or is compromised could sign a header off the + canonical chain, an expensive but real attack surface that verifying the full + validator set would avoid. It is the standard light-client trade-off, and the + proposal must state it plainly and quantify the cost of the attack it admits. +- **Weak-subjectivity checkpoint.** Sync-committee tracking only works starting + from a trusted checkpoint, a known-good committee, following handoffs forward + from there. That initial checkpoint is a trust anchor. The design is trustless + after bootstrap, given a correct starting committee, so the specification must + say how a verifier confirms the checkpoint independently, and when an instance + that has fallen outside the weak-subjectivity period must be replaced. + +Applicants may propose a stronger anchor than sync-committee tracking (full +validator-set verification, or a hybrid) and are encouraged to state the cost +trade-off explicitly if they do. The sync-committee path is the expected +baseline because it is what the light-client protocol supports today at +tractable in-zkVM cost. + +### Chain binding + +The attestation carries which chain and which chain ID it refers to, so a +statement valid for one network is never accepted as valid for another. This is +not incidental: the same contract address exists on mainnet and on every +testnet, and a design that omits the binding would let a testnet deposit satisfy +a mainnet predicate. + +### Uniqueness is the consumer's job, not the primitive's + +Two sub-problems sit inside "act on an Ethereum fact": + +1. **Existence.** Did the referenced Ethereum state actually occur on the + canonical Ethereum chain? +2. **Uniqueness.** Has this particular piece of Ethereum state already been + consumed on LEZ, so that it cannot be acted on twice? + +This RFP delivers existence. Uniqueness is solvable with mechanisms LEZ already +has: a consuming program records a nullifier or a program-owned account marking +a given Ethereum event as spent and rejects any second attempt. That is standard +double-spend protection, and it belongs to the consumer because only the +consumer knows what "the same action" means for its own application: a bridge +mint must be once-per-deposit, whereas a read-only escrow check may legitimately +be evaluated many times. + +The primitive must nonetheless make uniqueness enforceable. Every verified +statement carries a deterministic, collision-resistant identifier derived from +the attested state itself, so a consumer can key a nullifier on it without +inventing its own derivation and without two consumers deriving incompatible +identifiers from the same event. Guidance on doing this correctly is a +documentation deliverable (Supportability #4). + +### What the attestation does not do + +**It does not hide the underlying Ethereum activity.** Ethereum state is public +by construction. Amounts and timing of deposits and releases are visible on the +public chain, and linking them to LEZ activity is a separate privacy problem, +handled by the consuming application through fixed denominations, delayed +submission, and anonymity-set growth (see [RFP-022](./RFP-022-wrapped-erc20.md), +Design Rationale, "The privacy requirement, stated precisely"). What this RFP +must guarantee is narrower and still essential: verifying and consuming an +attestation must not itself add a new correlation signal beyond what Ethereum +already exposes. A consumer that does its own privacy work correctly must not +have that work undone by the attestation path, which is why the verified +statement's public inputs are constrained in Functionality #8. + +**It does not verify LEZ state on Ethereum.** The reverse direction, proving a +LEZ event natively on Ethereum, is specific to the bridge and stays in +[RFP-022](./RFP-022-wrapped-erc20.md). + +### Consumption model + +On testnet and mainnet the primitive is a deployed LEZ program with a published +interface, and a consumer calls it. Source-level availability matters for local +testing, review, and reproducing the cost measurements, but consumers do not +each compile and deploy their own copy of the verification logic, because doing +so would fragment the shared consensus state the architecture depends on and +multiply the audited surface. + +The program is deployed once and its code is immutable. Everything that varies +between chains is configuration held in accounts owned by that program: the +weak-subjectivity checkpoint, the chain binding, the finality parameters, and +the tracked consensus state. Each such namespace of accounts is an instance, +configured when it is initialised and never reconfigured after. A consumer binds +to a specific instance by address. + +What has to be atomic in the consumer's transaction is the part specific to that +consumer. Two things are being consumed and they differ: + +- **Verified consensus state**, the tracked committee and the finalised header + roots, is necessarily shared and necessarily written by an earlier + transaction. That is the point of the architecture, and it is safe because the + module verified the update when it was submitted: the consumer's trust rests + on that verification, not on the submitter's honesty. +- **Inclusion and predicate evaluation** must occur inside the consumer's own + transaction, against a header the consumer checks for itself, so that + verification and the action it authorises cannot come apart. + +A consumption path that records evaluated statements to a public account, so +that cost can be amortised when many consumers care about the same Ethereum +state, is a legitimate addition and is specified as a soft requirement. Where it +exists it must share a single verification core with the direct path, so the +audit surface and the cost profile stay common, following the pattern +established in [RFP-020](./RFP-020-redstone-oracle-adaptor.md). + +### Cost is a primary deliverable + +Where the cost lands depends on which execution path pays it, and the two are +not alike. A public transaction is executed by the sequencer, so in-program +verification cost is a throughput concern. A private transaction is proven on +the user's own device, so the same work becomes wall-clock latency in a user +flow, on whatever hardware that user has. + +The two verification steps use different primitives, and the split follows from +that. Establishing that a header is finalised means BLS12-381 aggregate +signature verification, which is pairing-based and heavy. Establishing that +state is included under that header is hashing down an SSZ and Merkle-Patricia +path, with no elliptic curve operations at all. + +BLS12-381 verification is needed only for headers, and a finalised Ethereum +header is public: every consumer reads it and none needs to hide it. +Sync-committee tracking therefore belongs on the public path, where submission +is periodic, latency-tolerant, shared, and executed by the sequencer rather than +proven on a user device. What has to be established there is throughput: whether +in-program BLS12-381 verification fits the per-transaction cycle budget at the +cadence tracking requires. This is the central feasibility question of the RFP. +If it does not fit, that measurement is the input to a follow-on RFP proposing a +BLS12-381 precompile for LEZ, reachable only from public transactions, which is +where this cost sits. + +The open question is the private path. A consumer that wants to use an +attestation privately has to prove inclusion verification on its own hardware, +and no existing measurement says whether that is viable. Hashing is cheap per +operation but repeats across the whole path, and whether the total lands inside +an interactive budget on a user's machine is unmeasured. That answer determines +whether the primitive is usable privately at all. + +Measuring and documenting both paths, separated by where the cost is paid, is +therefore a first-class deliverable and not a side report, exactly as it was for +RFP-020. Consumers cannot size their own designs without those numbers. + +### Assess reuse before rewriting + +[`r0vm-helios`](https://github.com/boundless-xyz/r0vm-helios) is an Ethereum +light client built on the RISC Zero zkVM, forked from SP1 Helios and +independently audited by zkSecurity. It implements the light-client logic this +RFP needs on the same zkVM LEZ runs on, which makes it a materially different +starting point from a blank sheet, as does Helios itself upstream. + +It is not a drop-in. It targets EVM destination chains with Solidity contracts, +and LEZ is neither. How much transfers, and whether the better base is one of +these zkVM forks or the upstream light-client implementations they derive from, +is a judgement the applicant is better placed to make than this specification. +That evaluation is itself work, and Reliability #6 scopes it as a deliverable. +Reuse is expected to be assessed seriously; it is not mandated. + +## ✅ Scope of Work + +### Hard Requirements + +Use FURPS framework. Each numbered item should be a testable statement. + +#### Functionality + +01. Run the Ethereum light client inside the LEZ program: given a trusted + starting checkpoint, the module verifies light-client updates and committee + handoffs against material supplied by the submitter, and follows the + canonical finalised chain forward without running a full node. The module + checks the sync-committee aggregate itself. +02. Verify that a supplied Ethereum block header is finalised, and reject any + header that is not. +03. Verify that a referenced piece of Ethereum state is included under a header + the module has verified as finalised, covering at minimum an account, a + contract storage slot, and an event log identified by its position within a + transaction receipt. The execution state reasoned about is bound to that + finalised header, so execution roots supplied by a caller are never trusted. + Reject any claim whose inclusion does not verify. +04. Evaluate a predicate over the verified state and emit a verified statement + asserting that the predicate holds of finalised Ethereum state. The + predicate interface must support at least equality and inequality + comparisons over attested values, and must be expressible by a consuming + program without modifying the module. +05. The verified statement binds the chain identity (network and chain ID) it + refers to. A statement produced against one chain must be rejected by a + verifier configured for another, tested across mainnet and at least one + testnet with the same contract address on both. +06. The verified statement carries a deterministic, collision-resistant + identifier derived from the attested Ethereum state, suitable for a consumer + to key a nullifier on. Identical Ethereum state yields an identical + identifier; distinct state yields a distinct one. +07. The module is deployed as a LEZ program with a published interface any + consuming program can call. Inclusion verification and predicate evaluation + occur inside the consuming transaction, and no consumption path requires a + consumer to act on a predicate result computed in an earlier transaction. +08. Verifying and consuming an attestation must not introduce any correlation + signal beyond what is already public on Ethereum. The public inputs of the + verified statement must be limited to what the consumer explicitly chooses + to expose, and must not reveal the identity of the consuming LEZ account or + the consuming transaction. This must hold over full event and state diffs. +09. The weak-subjectivity checkpoint, the supported chain and chain ID, and the + finality parameters are written into an instance's accounts when that + instance is initialised, and no later instruction changes them. The Logos + Ethereum core module exposes an API through which anyone can independently + verify an instance's checkpoint against public Ethereum sources before + relying on it. +10. An instance that has fallen outside the weak-subjectivity period is replaced + by a freshly initialised instance rather than refreshed in place. Document + when an instance must be replaced, and what a consumer must do to migrate to + a replacement. +11. Advancing the tracked consensus state is permissionless: any party may + submit a valid update, and submission carries no access control, allowlist, + role, or registration. An instance in which one party, or a set fixed at + initialisation, is the only entity able to advance the state does not + satisfy this requirement. An account with no prior relationship to the + instance can advance it. +12. Supplying update material and submitting it are liveness roles, not trust + roles: no specific party may be required for an attestation to be produced, + and any party declining to act must not block a user. Proposals must + identify every off-chain participant the design requires, state for each + whether it can affect safety or only liveness, and justify that none of + them, individually or as a class, can block an attestation from eventually + being produced. +13. The program exposes no instruction that rewrites an initialised instance's + checkpoint or chain configuration, whatever the caller. Recovery from a + mis-configured or stale checkpoint is by initialising a fresh instance, per + Functionality #10, not by mutating an existing one. +14. The design must not assume Ethereum mainnet is the only target. The same + program, unmodified, must support instances configured for any + Ethereum-consensus chain, mainnet or testnet, with the chain binding in + Functionality #5 keeping instances separate. +15. Multiple independent instances coexist under the same program, each with its + own checkpoint, chain configuration, and tracked consensus state, without + interfering with one another. A consumer binds to a specific instance, and a + statement from one instance is never accepted by a consumer bound to + another. + +#### Usability + +1. Build the attestation functionality for consumers and operators in a Logos + core module, so that different Logos ui modules can be built on it: producing + an attestation, verifying one, submitting a consensus-state update, and + reading the checkpoint and chain configuration of an instance. +2. Provide a CLI that covers producing an attestation for a given + `(chain, contract, storage slot or log, predicate)` tuple, verifying one + off-chain as a dry run, submitting a consensus-state update, and reading an + instance's configuration. The dry run must report the same typed error codes + the on-chain path returns. +3. Deliver the **update-submitting component**: a process that follows Ethereum + through the Logos Ethereum core module, detects when the tracked instance is + behind, and submits the outstanding light-client updates to LEZ. It must be + provided as a **Logos module accompanied by a Logos Core headless + CLI/daemon**, runnable standalone, supporting configurable Ethereum consensus + and execution RPC endpoints, structured logging, and a clean shutdown path. + Document the operator journey end-to-end: install, configure, run, monitor. +4. Provide an IDL for the LEZ-side module using the + [SPEL framework](https://github.com/logos-co/spel). +5. Return clear, actionable error messages for all failure modes: header not + finalised, sync-committee signature invalid, committee handoff not verified, + checkpoint stale or outside the weak-subjectivity period, inclusion proof + invalid, predicate not satisfied, chain-ID mismatch, and malformed input. +6. Provide **reference consumer programs** that demonstrate the recommended + consumer pattern of Supportability #4 end to end, covering at minimum two + cases: + - **ERC-20 transfer to a specific contract.** A transfer of a given ERC-20 + token to a specified Ethereum contract address, attesting the token, + recipient, sender, and amount, whether read from state or from an event, + whichever the design prefers. + - **Native ether transfer to a specific contract.** A transfer of native ETH + to a specified Ethereum contract address, attesting recipient, sender, and + amount, whether read from state or from an event, whichever the design + prefers. + +#### Reliability + +01. Verification is deterministic: the same inputs always yield the same + verdict, independently reproducible from the test suite. +02. Verification is read-only with respect to consumer state: a rejected + attestation consumes nothing and leaves the consumer able to retry. +03. A verified statement over a finalised header remains valid indefinitely. + Later Ethereum activity, including subsequent sync-committee rotations, must + never invalidate an attestation that was valid when produced. +04. Committee handoff tracking survives interruption: a component restarted + after an outage resumes from its last verified state without re-verifying + from the original checkpoint, and without accepting a handoff it has not + verified. +05. Temporary RPC or connectivity failure on the Ethereum side leaves any + off-chain component in a recoverable state, able to resume without + duplicating work already done. +06. Proposals must integrate mature, audited implementations of necessary + cryptographic primitives and the light-client protocol. Evaluating what + existing implementations offer, and stating what is reused, what is + rewritten, and the cost and audit-surface consequences of that split, is a + scoped deliverable to be budgeted in the proposal (see Design Rationale, + "Assess reuse before rewriting"). +07. An instance left unadvanced does not lose safety: attestations against + already-verified headers continue to verify, and a stalled instance resumes + correctly when any party submits the outstanding updates, with no manual + repair and no gap in the verified handoff chain. +08. Concurrent submission of the same update by competing operators is handled + without corrupting tracked state: a duplicate or already-applied update is + rejected cleanly rather than double-applied. +09. The update-submitting component checks whether an update is still needed + immediately before submitting, and does not submit one another party has + already applied. Running several instances against the same LEZ instance + must not multiply the gas spent on a given update beyond what contention + makes unavoidable. +10. Submission timing must not systematically concentrate cost on whichever + party reacts fastest. The component defers submission by an interval it + varies per instance, so that over many updates the gas cost is spread across + the operators running it rather than always falling on the same one, while + still submitting promptly once the deferral elapses and no other party has + acted. Document the deferral strategy and its effect on update latency. +11. Statement submissions are independent of one another, so that multiple + private transactions can submit statements in the same block, and a private + transaction can compute its resulting state before inclusion. +12. CI must be green on the default branch. + +#### Performance + +1. Verifying an attestation and evaluating its predicate must complete within a + single LEZ transaction at the per-transaction cycle budget in force at + delivery time, in the direct consumption path of Functionality #7. If this + proves infeasible at delivery time, the measurement in Performance #2 stands + as the deliverable and the shortfall must be documented with the specific + component responsible. +2. Cost measurement is a primary deliverable. Measure and document, with a + breakdown by program action: advancing the tracked Ethereum state, and + statement verification by type of statement. Report cycle count, gas cost, + proof time, and proof size for each, extending the measurement methodology + from [RFP-020](./RFP-020-redstone-oracle-adaptor.md). Numbers must be + reproducible from the test suite. +3. Document the amortised per-attestation cost of sync-committee tracking at the + recommended operating cadence, separately from the per-attestation + verification cost, since the two amortise differently across consumers. +4. Any proving the user's own device must perform has to be practical on the + desktop hardware Basecamp runs on. Measure and document wall-clock time and + peak memory on a mid-range laptop and on the lowest specification the team + declares as supported, and state that minimum explicitly. This includes + running the attestation in a private transaction. +5. Document end-to-end attestation latency, from the Ethereum event to a + verified statement usable on LEZ, broken down by finality wait, update + availability, and on-chain verification. +6. Document the compute resources (CPU, RAM, time) required to run any off-chain + component the design requires. +7. Document the growth rate and on-chain storage cost of any module state that + accumulates with usage, in particular committee-tracking state, with + projections over one and five years of continuous operation. +8. Document the cycle-count delta between the in-program BLS12-381 path and a + hypothetical native precompile, so the measurement can inform whether a + follow-on precompile RFP is warranted. A precompile is reachable only from + public transactions, which the comparison must state. +9. No action's cycle count or gas cost scales with accumulated on-chain storage. + Where a design cannot avoid it, the proposal justifies why and documents the + mitigations. + +#### Supportability + +01. The module is deployed and tested on LEZ testnet, attesting to state on a + public Ethereum testnet. +02. End-to-end integration tests exercise attestation production and consumption + against a LEZ sequencer (standalone mode) and an Ethereum test network or + local fork, and are included in CI. +03. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the core module, covering the developer integration journey for a + consuming LEZ program. +04. The consumer documentation must include a **"Recommended Consumer Pattern"** + section covering: enforcing uniqueness with a nullifier keyed on the + statement identifier from Functionality #6, verifying the chain binding + matches the consumer's expectation, handling each typed error code, and the + recommended behaviour when an attestation cannot be produced (refuse the + action, never fall back to an unverified input). +05. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the CLI and any operator-facing components, covering the core user and + operator journeys respectively. +06. Provide a **trust assumptions document** covering: the honest sync-committee + supermajority assumption and the cost of the attack it admits; the + weak-subjectivity checkpoint, who supplies it and how a verifier confirms it + independently; what an attestation does and does not prove; what every + off-chain participant in the design can observe; whether each can affect + safety or only liveness; and the conditions under which the guarantees + degrade or fail. +07. Document the operator role for an instance: what running an operator costs, + at what cadence updates should be submitted, how anyone can start one + without permission, what it requires (a consensus endpoint and LEZ gas, and + no standing on Ethereum), what an operator should expect when others are + running one concurrently, and how to detect that an instance has stalled. + State plainly that no party is obliged to operate and that liveness rests on + interested parties choosing to spend the gas. +08. The module undergoes an independent third-party security audit of the + consensus and inclusion verification logic before any mainnet-facing + deployment; the audit report must be published. +09. The deliverable must be published on the module catalog. +10. The repository must use the standard Logos GitHub Actions. + +#### + Verification Security + +1. Verification must reject a fabricated chain: given a self-consistent header + and inclusion proof over state that was never finalised on the canonical + chain, verification must fail. This is the central adversarial test of the + RFP and must be exercised explicitly, not implied by other tests. +2. Verification must reject: a header signed by a committee that was never + validly handed off from the configured checkpoint; a sync-committee signature + below the required participation threshold; a valid inclusion proof against a + header that is not finalised; a valid finalised header with a tampered state + or receipts root; a proof replayed against a different chain ID; and a + predicate asserted over state the inclusion proof does not cover. +3. **The verification logic cannot be swapped.** No consensus or inclusion + verification may be reached through a `ProgramId` held in mutable account + state. Change requires deploying a new version and having consumers move to + it; document the migration mechanism and what consumers must do. The consumer + documentation (Supportability #4) must state that the same rule applies to + consumers: a program holding this module's `ProgramId` in mutable state lets + whoever controls that pointer substitute a module that attests to anything. +4. Document the failure modes that follow from a compromised or colluding sync + committee, and what a consuming application can do to bound its exposure (for + example, caps and freeze authorities on the consumer side, as + [RFP-022](./RFP-022-wrapped-erc20.md) specifies). +5. User-facing and developer-facing documentation must state the trustless + verification model and the liveness-only role of any off-chain participant + (see Design Rationale, "The anchor: Ethereum finality via the sync + committee"). +6. An update is accepted on proof validity alone and never on the submitter's + identity: any account submitting a valid proof advances the state, and any + account submitting an invalid proof is rejected. + +### Soft Requirements + +1. **Recorded-statement account.** In addition to the direct path (Functionality + #7), provide a consumption path that evaluates a predicate and records the + resulting verified statement to a public account, so cost can be amortised + when many consumers care about the same Ethereum state. It must share a + single verification core with the direct path, following the pattern in + [RFP-020](./RFP-020-redstone-oracle-adaptor.md), so that the audit surface + and the cost profile stay common. Document that a consumer reading such an + account trusts whoever wrote it, which the direct path does not require. +2. **Batching.** Amortise verification cost across multiple attestations over + the same finalised header in a single transaction, analogous to the + multi-feed batching soft requirement in RFP-020. +3. **Historical state.** Attest to state under a header older than the + currently-tracked finalised head, for example via historical summaries in the + beacon state, so a consumer can prove a fact about Ethereum's past rather + than only its recent finalised present. +4. **Richer predicates.** Support predicates over multiple attested values in a + single statement (for example, an account balance and a storage slot under + the same header), so a consumer can express a compound condition without + producing and correlating several attestations. +5. **Operator incentive.** Propose a mechanism that rewards whoever advances the + consensus state, so that liveness does not rest solely on interested parties + choosing to spend the gas. Any such mechanism must preserve the + permissionless property in Functionality #11: it may make operating + attractive, but must not make it exclusive. + +### Out of Scope + +The following are explicitly excluded from this RFP: + +- **Verifying LEZ state or events on Ethereum.** The reverse direction is + specific to the bridge and stays in [RFP-022](./RFP-022-wrapped-erc20.md). +- **Any application action.** Minting, escrow release, settlement, and every + other action belong to the consuming program. This RFP emits a verified + statement and stops there. +- **Uniqueness enforcement.** The primitive supplies the statement identifier + (Functionality #6) and the guidance (Supportability #4); the nullifier or + spent-marker itself belongs to the consumer (see Design Rationale, "Uniqueness + is the consumer's job, not the primitive's"). +- **Hiding Ethereum-side activity.** Ethereum state is public by construction. + Unlinkability between Ethereum activity and LEZ activity is the consuming + application's problem; this RFP's obligation is only to avoid adding a new + correlation signal (Functionality #8). +- **Adding a BLS12-381 precompile to LEZ.** The in-program path is the + deliverable here. A precompile becomes a candidate for a follow-on RFP if and + only if the cost measurement in Performance #2 shows the in-program path is + too expensive for production use. +- **Circuit optimisation or custom zkVM accelerators.** LEZ runs on RISC0, so + proposals should leverage mature existing implementations rather than + implementing novel circuits or optimisation techniques. + +## ⚠ Platform Dependencies + +### Hard dependencies + +#### Event emission (LP-0012) + +Structured on-chain events let clients and off-chain components follow committee +handoffs and attestation submissions without polling every account. +[LP-0012](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0012.md) +is **closed** (delivered). + +#### Logos Ethereum core module + +Any Ethereum-side interaction, including fetching headers, update material, and +inclusion proofs, must use the Logos Ethereum core module, including its +verified proxy features. + +## 👤 Recommended Team Profile + +Team experienced with: + +- Ethereum consensus and the light-client protocol (sync committees, finality + updates, committee handoffs, weak subjectivity) +- BLS12-381 signature verification and aggregate signature schemes +- Merkle-Patricia trie proof verification against Ethereum state and receipts + roots +- LEZ program development and on-chain proof verification +- Security auditing of consensus verification logic (fabricated-chain attacks, + replay, committee-handoff attacks, checkpoint staleness) +- Designing libraries consumed by other protocol teams, including interface + stability and integration documentation + +## ⏱ Timeline Expectations + +Estimated software delivery duration: **8–12 weeks**. The scope is a single +primitive with no application logic, but sync-committee tracking, in-program +BLS12-381 verification, and the cost measurement deliverable are each +substantial. This excludes the third-party audit lead time required before any +mainnet-facing deployment (Supportability #8), which is typically procured and +scheduled separately. + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. + +## Resources + +- [RFP-003 — Atomic Swaps](./RFP-003-atomic-swaps.md) (trustless swap path for + chains without general smart-contract expressiveness) +- [RFP-020 — RedStone Off-Chain Oracle Adaptor for LEZ](./RFP-020-redstone-oracle-adaptor.md) + (reference for in-program verification cost measurement, and for the shared + verification core between two consumption paths) +- [RFP-022 — Privacy-Preserving Wrapped ERC-20 and Ether Bridge for LEZ](./RFP-022-wrapped-erc20.md) + (primary consumer; the mint side depends on this attestation) +- [RFP-023 — Native Gas Token Bridge for LEZ](./RFP-023-gas-token-bridge.md) + (consumer; the gas-token release path depends on this attestation) +- [Appendix: Ethereum Light Client Ecosystem](../appendix/ethereum-light-client-ecosystem.md) + (production zk light clients, operator models, and the permissioned-updater + counter-example) +- [Appendix: Bridges and Wrapped Tokens](../appendix/bridges-and-wrapped-tokens.md) + (bridge failure taxonomy, including verification-logic bugs) +- [LP-0012: Event/Log mechanism for LEZ](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0012.md) +- [Ethereum Altair light-client specification](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair/light-client) +- [Ethereum weak subjectivity specification](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [`boundless-xyz/r0vm-helios`](https://github.com/boundless-xyz/r0vm-helios) + (Boundless Ethereum light client, audited by zkSecurity; reuse candidate) +- [`succinctlabs/sp1-helios`](https://github.com/succinctlabs/sp1-helios) + (upstream implementation of the same pattern) + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, please use +**Discussions**. diff --git a/RFPs/RFP-022-wrapped-erc20.md b/RFPs/RFP-022-wrapped-erc20.md new file mode 100644 index 00000000..b6617f51 --- /dev/null +++ b/RFPs/RFP-022-wrapped-erc20.md @@ -0,0 +1,832 @@ +--- +id: RFP-022 +title: Privacy-Preserving Wrapped ERC-20 and Ether Bridge for LEZ +tier: L +status: open +category: Developer Tooling & Infrastructure +dependencies: + - id: RFP-021 + reason: The trustless Ethereum state attestation primitive is what the LEZ bridge program uses to verify a deposit really happened on Ethereum, as specified in Functionality. + - id: RFP-001 + reason: Admin authority governs the supported-token registry and the deposit/redemption caps, as specified in Functionality. + - id: RFP-002 + reason: Freeze authority provides the circuit breaker to halt minting and/or redemption, globally or per token, if a proof-system or vault vulnerability is suspected. + - id: LP-0013 + reason: Token authority primitives are required for the LEZ program to mint wrapped tokens on verified deposit, and burn them on redemption. +--- + + + +# RFP-022 — Privacy-Preserving Wrapped ERC-20 and Ether Bridge for LEZ + +> **Note.** This specification describes an outcome that may benefit the Logos +> ecosystem. It is a proposal rather than an instruction. Its requirements +> reflect the technical compatibility with the Logos technology stack and are +> the criteria against which proposals and milestones are evaluated. Logos makes +> no representation as to the legal or regulatory treatment of this +> specification or any implementation of it in any jurisdiction. +> +> Teams implementing it are solely responsible for (i) assessing the risks and +> implications of what they build; (ii) obtaining their own professional advice; +> and (iii) for complying with any legal and regulatory requirements that apply +> to them. Software developed under the Program is published and maintained by +> its developers, not by Logos. +> +> Anyone who chooses to deploy, host, operate or use software developed under +> the Program, whether or not they were awarded a grant under the Program, does +> so at their own risk and is solely responsible for complying with any legal or +> regulatory requirements that apply to them. See the +> [Terms & Conditions](../TERMS_AND_CONDITIONS.md). +> +> Deploying the software described in this RFP, operating any service based on +> it, or carrying on business through it may amount to regulated activity in +> some jurisdictions, including where it involves holding or managing users' +> assets or providing services to others. Whoever conducts any such activity +> does so as principal, in their own name, and is solely responsible for +> assessing its regulatory treatment, including any licensing, registration, +> sanctions or anti-money laundering obligations that may apply to them. Logos +> does not make any representation, provides any advice or assumes any +> responsibility in respect of any such determination or compliance. + +## 🧭 Overview + +Build a trustless, privacy-preserving lock-and-mint bridge that lets ERC-20 +tokens and native ETH, held on Ethereum, enter LEZ as canonical wrapped assets, +and exit back to Ethereum on redemption. + +An Ethereum-side vault contract escrows deposits. A LEZ-side program mints the +corresponding wrapped token once it has cryptographically verified, with no +trusted intermediary, that the deposit really happened on Ethereum; that +verification is the attestation primitive specified in +[RFP-021](./RFP-021-ethereum-state-attestation.md), which this RFP consumes +rather than rebuilds. Redemption reverses the flow: burning the wrapped token on +LEZ entitles the holder to release the original ERC-20 from the vault, again on +cryptographic proof alone. + +The bridge must **maximise privacy on both legs, minimising the linkability +between a specific Ethereum deposit and the LEZ mint it funded, or between a +specific LEZ burn and the Ethereum release it triggered.** This shapes the +design: the deposit should not name its LEZ destination, the burn should not +name its Ethereum destination, and information that would connect them should +stay with the user wherever the design permits it. Where a specific form of +linkability cannot be avoided, the proposal must document why and what residual +correlation results. + +Teams will need experience with zero-knowledge proof systems, privacy-preserving +protocol design, Solidity smart-contract development, and LEZ program +development. + +## 🔥 Why This Matters + +Thanks to LEZ's separated public/private state architecture and programmability, +and Logos Blockchain's Cryptarchia and Blend protocols, private DeFi is possible +with privacy guarantees at both the execution layer and the underlying consensus +layer. To let users move assets in from non-private blockchains such as +Ethereum, that move has to happen while preserving Logos' principle of +sovereignty: no custodian, signer, or federation should be trusted with a user's +assets or identity along the way. + +Wrapped tokens are what let users bring assets they already hold, and whose +value is already established, on Ethereum into that private DeFi, spending them +there directly or posting them as collateral: the privacy-preserving DEX +([RFP-004](./RFP-004-privacy-preserving-dex.md)), the lending protocol +([RFP-008](./RFP-008-lending-borrowing-protocol.md)), the reflexive stablecoin +([RFP-013](./RFP-013-reflexive-stablecoin-protocol.md)), and the price feeds +that collateralise them ([RFP-019](./RFP-019-twap-oracle.md), +[RFP-020](./RFP-020-redstone-oracle-adaptor.md)). This RFP delivers that +wrapping primitive for the Ethereum leg. Bitcoin, Monero, and Zcash reach LEZ +liquidity through a different route: direct, trustless swaps against LEZ assets +via [RFP-003](./RFP-003-atomic-swaps.md), rather than a wrapped representation, +noting that other strategies such as wrapped Bitcoin and synthetics are also +being considered. + +RFP-003 explicitly carved Ethereum out of its scope for this reason. Bitcoin, +Monero, and Zcash lack general smart-contract expressiveness, so a trustless +swap protocol, which needs a counterparty online at the same time to complete +the trade, is the only construction available for them. Ethereum's +programmability makes a wrapping bridge possible instead, and wrapping is the +better choice on every count that matters here: a deposit does not need a +counterparty to be online, so the exchange is non-interactive; it needs no +additional infrastructure such as a market of counterparties or order matching; +and unlike a swap, which merely trades an external asset for one already on LEZ, +wrapping creates a genuine LEZ-native representation of the external asset +itself, which is what lets it be deposited into an AMM pool, posted as loan +collateral, or otherwise composed with LEZ DeFi programs directly. + +### Minimising linkability between Ethereum and LEZ events + +Privacy is baked into LEZ, and this bridge should maximise privacy where it +touches a non-private chain. Ethereum is public: the deposit and the release it +eventually triggers are visible to anyone. A conventional lock-and-mint bridge +adds to that a deposit event naming both the Ethereum depositor and the LEZ +recipient, and a redemption event naming the Ethereum destination alongside the +LEZ account that funded it, each permanently binding a traceable Ethereum +identity to LEZ activity for anyone to read. + +The applicant must consider and document the bridge's strategy for reducing +linkability between an Ethereum deposit and the LEZ mint it funds, and between a +LEZ burn and the Ethereum release it triggers. Where a specific form of +linkability cannot be avoided, given what a lock-and-mint bridge to a public +chain necessarily reveals, the applicant must document why, and what residual +correlation an observer is left with as a result. + +### Stablecoins are the concrete prize + +A healthy DeFi ecosystem needs a variety of assets available as collateral and +liquidity: native LEZ assets, wrapped assets, and synthetics each have a role, +and wrapping is one strategy among those we want to see implemented, not the +only one. USDT and USDC together account for over 80% of a stablecoin market +that stood above $300B in mid-2026, and are the settlement asset most DeFi money +markets and DEXes actually run on, which makes them a concrete target for this +strategy: wrapping USDC, USDT, DAI, and WETH gives the lending protocol and the +reflexive stablecoin a credible collateral base at launch. + +### Bridge risks: hacking + +Chainalysis found that cross-chain bridge protocols accounted for 64% of the +$3.1B stolen from DeFi in 2022, the single largest category that year. A large +share of that historical loss traces to compromised custody of validator or +multisig keys (Ronin, Harmony Horizon, Multichain); this RFP's cryptographic +verification design is aimed directly at that vector, since it requires no +signer, validator, or federation to be trusted with a key at all. But key +custody is not the only cause, and by some reasonable ways of counting is not +even the largest: a comparable or larger share of losses (Wormhole, Nomad, BNB +Bridge, Poly Network) came from bugs in verification logic itself, a risk a +cryptographic design does not remove, because it depends on that logic being +correct (see +[Appendix: Bridges and Wrapped Tokens](../appendix/bridges-and-wrapped-tokens.md) +for the sourced figures, per-hack root causes, and the exact Chainalysis +citation). This RFP therefore does not want mutable verification logic, which +carries two distinct risks: whoever can change it can point the bridge at a +verifier that accepts anything, and an upgrade made in good faith can ship a +catastrophic bug. The first has no documented cross-chain bridge example; the +second caused Nomad (~$190M) and nearly caused a second Ronin incident in 2024 +($12M, returned). This RFP treats verification logic correctness (audit, formal +methods, extensive adversarial testing) as a security requirement of the same +order as eliminating signer trust. Per-token and global caps and an +admin-governed freeze authority remain as operational safety nets against both +failure modes. + +## 🏗 Design Rationale + +### The privacy requirement, stated precisely + +Deposit amount and depositor address, and release amount and recipient, are +public on Ethereum by construction: ordinary token transfers, not designed away. +The hard requirement is precise about what it covers instead: **no information +other than amount, token, and timing may enable an adversary who observes all +public state on both chains, indefinitely, and who may themselves deposit and +redeem, to link an Ethereum deposit to the LEZ mint it funded, or a LEZ burn to +the Ethereum release it triggered.** + +- **Inbound.** No signal other than amount, token, and timing may narrow down + which LEZ mint an Ethereum deposit funded, beyond uniform probability over the + remaining candidates. Formalised as a testable requirement in Privacy + Preservation #1, below. +- **Outbound.** No signal other than amount, token, and timing may narrow down + which Ethereum release a LEZ burn triggered, beyond uniform probability over + the remaining candidates. Formalised as a testable requirement in Privacy + Preservation #2, below. + +Both are stated relative to this *anonymity set*, the candidates amount, token, +and timing leave unresolved, and degrade to nothing when that set is small. +Sizing and minimising it (amount and timing above all, see Soft Requirement 1, +Hidden amounts, below) is a first-class requirement. Privacy comes from making +these public facts *uninformative about which counterparty they pair with*, not +from hiding them. + +Three further consequences follow from what cannot be hidden, and proposals must +address each: + +- **Amounts correlate.** A deposit of 1,337.42 USDC followed by a mint of + 1,337.42 wUSDC is matched by elimination regardless of what cryptography sits + between them. The amount visible on the Ethereum side must not act as a + fingerprint. Restricting transfers to a fixed set of per-token denominations + is the simpler and better-understood mitigation, and is the expected baseline + for this RFP; hiding amounts outright via value commitments is stronger but + considerably heavier, and is specified as a soft requirement below. +- **Timing correlates.** A deposit followed promptly by a mint, at a quiet + moment, is matched by inspection. The protocol must not force users into + correlated timing, and the UI must encourage some delay. +- **Fee payers correlate.** If the user pays their own gas to mint or release, + the funding source of that account re-identifies them and the construction + collapses. Permissionless relayers paid out of the bridged amount are the + conventional mitigation, with the destination bound into the proof so a + relayer cannot redirect funds or overcharge. + +### Trust model + +This bridge is **trustless**. It requires no trust in signers, validators, +attestor federations, relayers, or proof-generation services. A user relies only +on the correctness of the proof system, the security of the Ethereum network, +and the security of the LEZ network. + +The protocol should not depend on any specific off-chain participant at all: a +deposit or burn should not need a particular counterparty online to complete, +consistent with the non-interactive design this RFP requires (see Why This +Matters). Where an off-chain participant is unavoidable, for example relaying a +transaction or generating a proof, that role must be permissionless so any +single participant declining to act never blocks the user, and no participant +may be trusted with anything beyond that: never able to steal, redirect, forge, +censor selectively, or deanonymise. Proposals must identify every such +participant and justify that none of them, individually or as a class, can block +a user's deposit or burn from eventually completing. + +Caps and the freeze authority remain in place as operational safety mechanisms +independent of the cryptographic trust model. Note that the freeze authority can +necessarily operate at token and protocol granularity only: it cannot freeze an +individual user's holdings, because the protocol does not know whose are whose. +This is a designed consequence of the privacy guarantees, not a gap, and must be +documented as such. + +### Loss of access + +Once minted, a wrapped token is an ordinary LEZ token: whoever holds it, however +they acquired it (received directly from their own deposit, or bought on an AMM +from someone else), can burn it and claim the underlying Ethereum asset. +Redemption depends only on holding the token, never on the original depositor's +credentials. + +The credentials-recovery problem is narrower than that, and specific to the two +windows where a claim is outstanding: between depositing on Ethereum and +claiming the mint on LEZ, and between burning on LEZ and claiming the release on +Ethereum. In any design meeting these requirements, the protocol cannot identify +who owns what, so there is no administrative recovery path if a user loses +access to a deposit or burn before it is claimed. This is the largest UX risk in +the RFP and must be designed against rather than disclaimed: a user must be able +to recover every one of their own unclaimed deposits and unreleased burns from +their existing wallet seed alone, with no other information and no separately +backed-up secret. Concretely, if data loss occurs between lock and mint, or +between burn and release, the client must be able to rediscover and re-derive +everything it needs from the user's seed plus on-chain state, with no dependence +on locally-cached state that isn't recoverable that way. A construction where +the claim or entitlement data can be regenerated from on-chain events or state +(for example, re-deriving a proof from a deposit event the user's own keys can +scan for) is preferred over one that generates an ad hoc secret at deposit or +burn time with no on-chain trace, since the latter is unrecoverable the moment +that secret is lost, however it was backed up. + +### Token registry and decimal normalisation + +The registry is admin-curated rather than permissionless: anyone can deploy an +ERC-20 on Ethereum, and a bridge that minted a wrapped representation for any +token a depositor names would inherit every failure mode of an open listing +process. Curation defends against several distinct problems a permissionless +registry cannot: + +- **Metadata and configuration errors.** A wrong symbol, name, or decimals value + in the LEZ mint, whether an honest mistake or deliberate, corrupts every + downstream integration that reads that metadata, and is exactly the class of + error the decimals-conversion requirement below exists to catch. Curated + registration is the point at which that check happens. +- **Scam and impersonation tokens.** A permissionless registry lets anyone + deploy a token with a name or symbol crafted to be confused with an + established asset, and have the bridge mint a wrapped version + indistinguishable in a wallet UI from the real thing. Curation is what + prevents the bridge itself from becoming a vector for that. +- **Unbounded registry growth.** Every registered token adds to on-chain state + that the bridge program and its clients must read and iterate over; an + open-ended, permissionless list of approved tokens has no bound on this cost, + where a curated registry does. + +Because the design is open source, and supports multiple independently +configured entities on both chains (Functionality #16), curation also enables +competition: multiple entities or DAOs can each run their own configuration, +with their own token registry and admin policy, competing on the quality of +curation and the resulting reputation of their specific wrapped tokens, rather +than the ecosystem depending on one canonical, centrally-curated list. + +Each supported ERC-20 is registered individually by the admin authority: its +Ethereum contract address, its LEZ wrapped-token mint, its decimals, its +permitted transfer amounts, and its per-token caps. ERC-20 tokens do not share a +common decimals convention (6 for USDC, 8 for WBTC, 18 for WETH and DAI); the +wrapped LEZ mint for each token must document its own decimals and the exact +conversion applied on mint and burn, and registration must reject any token +whose values cannot be represented exactly in the chosen LEZ mint precision. + +### Finality and reorg protection + +Wrapped tokens must not be minted against an Ethereum deposit that a reorg could +still remove, and the vault must not release against a LEZ burn that is not yet +final. Both directions require a configured finality condition on the source +chain. The chosen depth is a direct trade-off between user-facing latency and +reorg risk; proposals must recommend a specific default depth for each direction +and document the residual risk it leaves. The depth must also be configurable by +the admin authority per deployment, for the same reason the token registry is +(see "Token registry and decimal normalisation" above): different deployers may +reasonably want to strike the latency-versus-risk balance differently, and a +fixed, hard-coded depth would foreclose that choice. + +Once a user's claim is valid it must remain valid indefinitely, since users are +expected to delay their own submissions for privacy reasons and must never be +forced to act promptly to avoid expiry. + +### Fee structure + +This RFP mandates a protocol fee on both minting (deposit-side) and burning +(redemption-side) of the wrapped token on LEZ. The rate itself is not mandated: +it must be configurable by the admin authority per deployment, for the same +reason the token registry and finality depth are (see "Token registry and +decimal normalisation" and "Finality and reorg protection" above), so different +deployers can compete on sustainability and fee policy rather than being locked +into one rate. This RFP does not mandate a fee on the Ethereum side; the focus +here is the Logos ecosystem and its privacy-preserving LEZ side, and an +Ethereum-side protocol fee is left to the proposal if it chooses to specify one. + +Configuration proposals must specify: + +1. **Denomination.** Whether the fee is charged in the wrapped token itself, in + native LEZ tokens, or a mix of both, with the design rationale for the + choice. Charging in the wrapped token keeps the fee self-contained to the + asset being bridged and requires no separate LEZ balance from the user; + charging in native LEZ tokens routes value to the LEZ token instead and + requires the user (or their relayer) to hold it. Proposals may support more + than one denomination if the admin authority can select between them per + deployment. +2. **Rate.** The initial rate and range, and the mechanism (a + governance-activatable fee switch gated by the admin authority per RFP-001 is + the expected baseline) by which the admin authority adjusts it per + deployment. +3. **Collection point.** Whether the mint-side fee is deducted at claim time, + and the burn-side fee at burn or at release, and how partial amounts (after + fee deduction) interact with the fixed-denomination requirement in "The + privacy requirement, stated precisely," above. +4. **Routing.** The destination of collected fees (protocol treasury, relayer + compensation, burn, or a combination). + +Whatever the denomination and rate, any fee paid by a user (protocol or relayer) +must take a value that does not distinguish their transaction from others, since +a distinctive fee is itself a fingerprint; this constraint applies regardless of +which token the fee is charged in. + +### One program pair = one chain pair + +A given instance of the LEZ program, under a given configuration, supports a +single EVM chain ID. The reason is blast-radius containment: an incident on one +EVM chain, whether a reorg, a consensus bug, or a compromised token contract, +should not contaminate the wrapped supply backed by another chain. + +This raises the question of whether USDC deposited from EVM chain A should be +represented by the same LEZ token as USDC deposited from EVM chain B. Separation +reduces risk, since a failure on one chain leaves the other chain's wrapped +supply untouched. Unification increases liquidity, and increases privacy, since +a mint of USDC on LEZ could then have originated from any of several chains, +enlarging the anonymity set. + +This RFP is written assuming separation, and Functionality #15 and Soft +Requirement #5 reflect that. Applicants are welcome to argue for either +direction, with the reasoning made explicit. + +## ✅ Scope of Work + +### Hard Requirements + +Use FURPS framework. Each numbered item should be a testable statement. + +#### Functionality + +01. Implement an EVM smart contract vault that escrows deposits of any ERC-20 in + the supported-token registry, plus native ETH deposited directly: a user + locking ETH must not be required to convert it to WETH or any other ERC-20 + themselves first. +02. A deposit must not publish, store, or otherwise reveal its LEZ destination. + No Ethereum transaction argument, event, or contract state may identify the + account that will receive the wrapped tokens. +03. Implement a LEZ bridge program that mints the corresponding wrapped token on + cryptographic verification of a valid Ethereum deposit. Verification must + require no trusted party, and must consume the attestation primitive from + [RFP-021](./RFP-021-ethereum-state-attestation.md) rather than implementing + its own Ethereum consensus and inclusion verification. Uniqueness (that one + deposit cannot be minted against twice, per Reliability #3) is this + program's responsibility, keyed on the statement identifier the attestation + carries. +04. Minting must support both a private LEZ account and a public LEZ account as + the destination, at the depositor's choice. +05. Implement a burn path on the LEZ bridge program that entitles the holder to + release the original asset from the Ethereum vault. The burn must not + publish, store, or otherwise reveal its Ethereum destination. +06. Burning must support the wrapped token being held in, and burned from, + either a private or a public LEZ account, at the holder's choice. +07. The Ethereum vault releases the original asset (the deposited ERC-20, or + native ETH) on cryptographic verification of a valid LEZ burn, verified + natively on Ethereum. +08. The amounts visible on Ethereum must not identify which mint or burn they + correspond to. Proposals must state the mechanism chosen (fixed + denominations are the expected baseline) and its effect on anonymity-set + size. +09. A user must be able to recover every one of their own unclaimed deposits and + unreleased burns from credentials they already hold, with no dependence on + any server-side index and no separately-backed-up secret generated during + the flow. This does not extend to the wrapped token itself: once minted, it + is an ordinary LEZ token redeemable by whoever holds it, regardless of who + made the original deposit. +10. An admin authority (per RFP-001) can register a supported ERC-20 (Ethereum + address, LEZ wrapped mint, decimals, permitted amounts, caps) and deregister + a token. Documentation needs to be provided to handle registration changes + with minimum impact for users, including delisting of a token. +11. Global and per-token deposit and redemption caps, configurable by the admin + authority, bound the maximum value that can be minted or released within a + rolling window, as a rate limiter independent of the freeze authority. Cap + enforcement per blockchain account is sufficient. +12. The finality depth required before a deposit may be claimed, and before a + burn may be released, is configurable by the admin authority per deployment, + defaulting to the depth recommended in Design Rationale, "Finality and reorg + protection." A change to the configured depth must not invalidate a claim or + release that was already valid under the previous depth. +13. A protocol fee can be charged on both minting and burning of the wrapped + token on LEZ, in a denomination (wrapped token, native LEZ token, or a + configurable mix, per Design Rationale, "Fee structure") and at a rate + configurable by the admin authority per deployment. The fee value must not + distinguish a user's transaction from others, consistent with Functionality + #8. The admin can also set either fee to zero. +14. A freeze authority (per RFP-002) can pause minting and/or redemption, either + globally or for a single registered token, on the Ethereum vault and the LEZ + bridge program independently. +15. Each LEZ bridge program deployment refers to a specific EVM smart contract + deployment on a specific chain (contract address plus chain ID as the + identifier), and reciprocally, each EVM smart contract deployment refers to + a specific zone instance (LEZ blockchain ID, zone ID, and program ID). The + design must not assume Ethereum mainnet is the only chain a deployment can + target: the same program and contract design must be deployable, unmodified, + against any EVM chain, mainnet or testnet, with each pairing checked as part + of proof verification so a deposit or registration valid for one pairing is + never accepted as valid for another. +16. The design must let multiple entities each operate under their own + independent configuration (token registry, fee recipients and rates, admin + authority, caps, finality depth) on the same or different pairs of + blockchain programs, with strict separation between them: one entity's + configuration must have no privileged access over another's configuration or + funds, as if each were a fully separate deployment. Document how a client + identifies and switches between configurations. + +#### Usability + +01. Build core functionalities for both users and admin in a Logos core module, + enabling the delivery of different Logos ui modules to use these programs: + depositing, claiming a deposit on LEZ, redeeming, releasing on Ethereum, + recovering a position from user credentials, and reading and administering + the supported-token registry and its permitted amounts. +02. Provide a Logos mini-app, aka Logos ui module, covering the deposit and + redemption flows end to end, position recovery, and a registry view showing + supported tokens, permitted amounts, caps and current utilisation. Also + provide a UI for the admin functionality; whether this is combined into one + UI or delivered as two separate ones is left to the applicant's choice. +03. Any long-running off-chain component the design requires must be provided as + a **Logos module accompanied by a Logos Core headless CLI/daemon**, runnable + standalone, using LEZ module and Ethereum module for the respective chains + access, configurable finality depth, structured logging, and a clean + shutdown path. Document the operator journey end-to-end: install, configure, + run, monitor. +04. Provide an IDL for the LEZ bridge program using the + [SPEL framework](https://github.com/logos-co/spel). +05. The mitigations to the three correlation points in Design Rationale, "The + privacy requirement, stated precisely" (amount, timing, fee payer) must be + enabled by default for users. The mini-app and CLI must show a clear + indicator of what data would be leaked by the user's current choices, and + default to the recommended parameters (fixed denomination, delayed + submission, permissionless relayer) rather than requiring the user to select + them. +06. Although minting and burning both support public LEZ accounts (Functionality + #4, #6), the mini-app and CLI must default to inviting the user to mint + into, and burn from, a private account: the private path is the pre-selected + option in the flow, and choosing the public path instead requires an + explicit action, consistent with Privacy Preservation #7. +07. Documentation and UI must clearly explain what is public and what is private + at each step on both chains, so users can judge their own exposure. +08. Return clear, actionable error messages for all failure modes: unsupported + token, invalid amount, cap exceeded, verification failure, insufficient + finality, already claimed, and program or per-token frozen. Error messages + must not reveal which deposit or burn a failed attempt referred to. +09. The UI must let users change the targeted Ethereum RPC address and the + targeted LEZ sequencer or zone. +10. All resulting modules are published in catalogue for easy installation. + +#### Reliability + +01. Minting is atomic: a failed or rejected claim leaves the deposit claimable + on retry and consumes nothing. +02. Redemption is atomic at each stage: a failed burn does not destroy wrapped + tokens without preserving the holder's entitlement to release, and a failed + release leaves that entitlement intact. +03. No deposit can be claimed twice and no burn redeemed twice, + deterministically and under adversarial retry. +04. A valid claim remains valid indefinitely; later chain activity must never + invalidate a user's outstanding entitlement. +05. Position recovery is complete: a client restored from user credentials + alone, with no local state, rediscovers every claimable deposit and + unredeemed burn. +06. Temporary RPC or connectivity failure on either chain leaves any off-chain + component in a recoverable state, able to resume without duplicating work + already done. +07. An interrupted user-side operation does not consume, corrupt, or expose the + user's entitlement. +08. Proposals must integrate mature, audited proof-system implementations rather + than reimplementing zero-knowledge primitives from scratch. +09. If any off-chain component is necessary, and expected to be run by a 3rd + party, document the effect, and mitigate it, of an outage or malfunction of + said component. +10. End-to-end integration tests exercise the full deposit and redemption round + trip against a LEZ sequencer (standalone mode) and an Ethereum test network + or local fork, and are included in CI. +11. Every hard requirement has at least one corresponding test. +12. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the core module, covering the developer integration journey for both + flows including position recovery. +13. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the CLI and any operator-facing components, covering the core user and + operator journeys respectively. +14. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the deployer journey, covering how an entity stands up its own + independently configured deployment (Functionality #16): registering tokens, + setting fees, configuring the admin and freeze authorities, and the finality + depth. + +#### Performance + +1. Verifying an inbound claim and minting must complete within a single LEZ + public transaction at the per-transaction compute budget in force at delivery + time. Document the compute-unit cost with a breakdown by component, extending + the measurement methodology from + [RFP-020](./RFP-020-redstone-oracle-adaptor.md). +2. Document the compute-unit cost of any additional LEZ-side verification the + design requires beyond the per-claim path, and its amortised per-deposit cost + at the recommended operating cadence. +3. Document the Ethereum-side gas cost of a deposit, of a release, and of any + additional on-chain verification the design requires. +4. Any proving the user's own device must perform has to be practical on the + desktop hardware Basecamp runs on. Measure and document wall-clock time and + peak memory on a mid-range laptop and on the lowest specification the team + declares as supported, and state that minimum explicitly. +5. Document end-to-end deposit latency (deposit to LEZ mint) and redemption + latency (burn to Ethereum release), each broken down by source-chain finality + wait, proof generation, any privacy-motivated delay, and on-chain + verification. +6. Document the compute resources (CPU, RAM, time) required to run any off-chain + component the design requires. +7. Document the growth rate and on-chain storage cost of all bridge state that + accumulates with usage, with projections at 1M and 10M operations. + +#### Supportability + +1. The Ethereum vault contract and the LEZ bridge program are deployed and + tested on a public Ethereum testnet and LEZ testnet respectively. +2. The modules work on both Linux and MacOS platforms. +3. The repository must use the standard Logos GitHub Actions. + +#### + Security + +1. Both blockchain contracts undergoes an independent third-party smart-contract + security audit before mainnet deployment; the audit report must be published. +2. Proof verification must be independently verifiable. Both the LEZ program and + the Ethereum vault must reject invalid proofs, including those with incorrect + public inputs, proofs for incorrect chain state, tampered headers, and + replayed proofs. +3. A malicious party submitting on a user's behalf must not be able to redirect + funds, inflate their fee, or replay the user's submission to a different + destination: a deposit and a burn must each secretly commit to the + destination on the other chain, so that the claim can only be completed by + whoever holds the seed or credentials that produced the commitment, and no + information that leaks beyond that seed, whether from the deposit or burn + transaction itself, public or observable state, or any party the flow depends + on, can be used to steal it (see Functionality #2, #5). An adversary who + observes everything public about a deposit or burn, but does not hold the + originating seed, cannot construct a valid claim for a different destination. +4. Caps (Functionality #11) bound the maximum value at risk in any rolling + window; proposals must document recommended defaults and the reasoning behind + them. +5. The freeze authority (Functionality #14) must be exercisable independently on + each half, so either can be paused without the other being operational or + reachable. +6. Soundness of supply: total wrapped supply on LEZ must never exceed the + vault's holdings. Minting without a valid deposit, minting twice from one + deposit, and releasing without a valid burn must all fail. +7. User-facing documentation must state the trustless verification model and the + liveness-only role of any off-chain participant (see Design Rationale, "Trust + model"). +8. **The verification logic cannot be swapped.** No party may change what the + bridge accepts as a valid proof after deployment. Change requires deploying a + new version and migrating to it. Proposals must document the migration + mechanism and how in-flight deposits and burns are honoured across it. +9. The freeze authority (Functionality #14) stops new activity but does not by + itself recover funds already at risk or resolve deposits and burns left + in-flight once a vulnerability in the verification logic is found. Proposals + must specify a failsafe strategy for this scenario, constrained as follows: + the failsafe must not become a backdoor, meaning any recovery must still be + claimed by the depositor or burner proving their own entitlement, the same + way an ordinary claim or redemption works (see Design Rationale, "Trust + model" and "Loss of access"), not by an admin authority or any other party + identifying who owns what and redirecting funds on their behalf; it must not + be able to mint, redirect, or release funds to any destination other than the + address or account the proof specifies; and it must not be able to act on + funds beyond what a specific, proven vulnerability put at risk. If no + mechanism satisfying these constraints is achievable, the proposal must + instead document explicitly why a failsafe should not be implemented, and + what happens to affected funds and in-flight positions in its absence. + +#### + Privacy Preservation + +1. **Inbound unlinkability.** No signal other than amount, token, and timing may + narrow down which LEZ mint an Ethereum deposit funded. Across the anonymity + set those three signals leave unresolved, no correlation derivable from + public state identifies the true deposit-to-mint pairing better than chance. +2. **Outbound unlinkability.** No signal other than amount, token, and timing + may narrow down which Ethereum release a LEZ burn triggered. Across the + anonymity set those three signals leave unresolved, no correlation derivable + from public state identifies the true burn-to-release pairing better than + chance. +3. No transaction argument, event, log, or account-state change on either chain + may reveal a deposit's LEZ destination or a burn's Ethereum destination. This + must hold over full event and state diffs for a complete round trip. +4. Information that would connect the two legs must never leave the user's + control. Document every component that handles user data; such information + must be absent from all submitted transaction data. +5. Failure and error paths must not reveal which deposit or burn was involved: a + rejected claim, a repeat claim, and a cap rejection must be indistinguishable + in that respect. +6. Where a third party submits on the user's behalf, document precisely what + that party learns, and ensure the user can switch between such parties per + operation. +7. The default configuration must be the private one. No user action may be + required to obtain the privacy guarantees, and any override that weakens them + must require explicit confirmation. + +### Soft Requirements + +1. **Hidden amounts.** Remove the amount-visibility constraint entirely by + concealing transferred values on the LEZ side, rather than relying on a fixed + set of permitted amounts. This merges all per-amount anonymity sets into one + and reduces the need for users to split transfers. Whatever is delivered + under the hard requirements should be designed so this can be adopted later + without redeploying the vault or resetting accumulated anonymity; document + the intended migration path even if it is not implemented. +2. Optional viewing keys allowing a user to *voluntarily* disclose their own + bridge activity to a chosen third party, without weakening privacy for anyone + else and without any protocol-level disclosure capability. +3. A configurable per-token release delay, in addition to finality and any + user-chosen delay, as an extra circuit-breaker window allowing the admin + authority to react to anomalous redemption volume before funds leave the + vault. +4. Design the proof-system components as pluggable, so that future zkVM + improvements, proof compression, or hardware acceleration can be adopted + without restructuring the vault or the bridge program (redeployment and + migration would be necessary, per Security #8) + +### Out of Scope + +The following are explicitly excluded from this RFP: + +- Wrapping non-fungible assets (ERC-721, ERC-1155). +- Network-level anonymity. The guarantees here are properties of on-chain state. + IP-level correlation between a user's Ethereum deposit and their later LEZ + activity is out of scope as an implementation concern, but must be disclosed + as residual leakage under Privacy Preservation #6. +- Protocol-level compliance, disclosure, or selective-deanonymisation + mechanisms. Voluntary user-held viewing keys are Soft Requirement #2; any + capability allowing a third party to deanonymise a user without their consent + is contrary to the design and out of scope. +- Circuit optimisation or custom zkVM accelerators for the LEZ side: LEZ itself + runs on RISC0, so proposals should leverage mature existing implementations + (e.g. Zisk) for LEZ-side proving rather than implementing novel circuits or + optimisation techniques. This RFP does not mandate a specific proof system for + verifying LEZ state and events on Ethereum; that choice is left to the + proposal. + +## ⚠ Platform Dependencies + +### Hard dependencies + +#### Ethereum state attestation (RFP-021) + +The inbound leg mints only against a deposit proven to have been finalised on +Ethereum, with no signer or federation trusted to attest to it (Functionality +#3). That verification, establishing Ethereum finality, proving inclusion of the +deposit under a finalised header, and emitting a verified statement, is +delivered as a shared primitive by +[RFP-021](./RFP-021-ethereum-state-attestation.md). This RFP consumes it and +does not rebuild it, so that the consensus verification path is audited once and +shared with the other LEZ programs that need to read Ethereum state. The +outbound leg, verifying a LEZ burn natively on Ethereum, is specific to this +bridge and remains in scope here. + +#### Admin authority (RFP-001) + +The Functionality requirements specify that an admin authority registers and +deregisters supported tokens and configures permitted amounts and caps. These +admin-gated functions require the standardised admin authority library from +[RFP-001](./RFP-001-admin-authority-lib.md). + +#### Freeze authority (RFP-002) + +The Bridge Security requirements specify a freeze authority able to pause +minting and/or redemption, globally or per token, as a circuit breaker +independent of the caps. This requires the standardised freeze authority library +from [RFP-002](./RFP-002-freeze-authority-lib.md). + +#### Token authorities (LP-0013) + +The LEZ bridge program mints wrapped tokens on verified deposits and burns them +on redemption. This requires the token authority primitives in +[LP-0013](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0013.md), +which is **closed** (delivered). The design must work with the existing LEZ +token program, and wrapped-token accounts must be compatible with ATA +(Associated Token Account) derivation, consistent with +[RFP-004](./RFP-004-privacy-preserving-dex.md). + +#### Logos Ethereum core module + +The Ethereum side must use the Logos Ethereum core module, including its +verified proxy features. + +#### Wallet SDK + +The UI must use the wallet SDK from the Lambda Prize wallet-SDK work. + +#### RISC0 zkVM + +The bridge verifies proofs in-program on LEZ (the deposit attestation from +RFP-021 on the inbound leg, and the bridge's own claim and burn logic +throughout). Because LEZ itself runs on RISC0, a production-ready zkVM, this leg +of the design is a LEZ-runtime dependency rather than a choice the proposal +makes; proposals must leverage mature RISC0 implementations (e.g. +[Zisk](https://github.com/risc0/zisk)) for LEZ-side proving rather than building +custom circuits. + +#### Event emission (LP-0012) + +Structured on-chain events allow clients and off-chain components to react +without polling every account. +[LP-0012](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0012.md) +is **closed** (delivered). + +## 👤 Recommended Team Profile + +Team experienced with: + +- Zero-knowledge proof systems and RISC0 zkVM (guest program development, proof + generation and verification, public/private input handling) +- Privacy-preserving protocol design, including anonymity-set analysis and the + ability to reason rigorously about what public state does and does not reveal +- Solidity smart-contract development, including experience preparing a contract + for third-party security audit, and EVM precompile integration +- Cryptographic primitives (Groth16 verification, Merkle proofs, consensus + verification, state root inclusion proofs) +- LEZ program development, private-state programs, and on-chain proof + verification +- Smart-contract security auditing (proof validation, replay attacks, reorg + handling, cap bypass, privacy-leak analysis) +- Cross-chain system design and integration testing (dual-chain atomic + operations, finality assumptions, determinism and reproducibility) + +## ⏱ Timeline Expectations + +Estimated software delivery duration: **16–20 weeks**. This is longer than a +transparent lock-and-mint bridge would require; the privacy construction, +user-side proving, position recovery, and the privacy test suite are the +additional scope. This excludes the third-party audit lead time required before +mainnet deployment (Security #1), which is typically procured and scheduled +separately. + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. + +## Resources + +- [RFP-001 — Admin Authority Library](./RFP-001-admin-authority-lib.md) +- [RFP-002 — Freeze Authority Library](./RFP-002-freeze-authority-lib.md) +- [RFP-003 — Atomic Swaps](./RFP-003-atomic-swaps.md) (trustless path for BTC, + XMR, ZEC; explicitly defers ETH to wrapping) +- [RFP-004 — Privacy-Preserving DEX](./RFP-004-privacy-preserving-dex.md) + (downstream consumer whose privacy guarantees depend on a private on-ramp) +- [RFP-008 — Lending & Borrowing Protocol](./RFP-008-lending-borrowing-protocol.md) + (primary consumer of wrapped collateral) +- [RFP-013 — Reflexive Stablecoin Protocol](./RFP-013-reflexive-stablecoin-protocol.md) + (consumer of wrapped-asset collateral) +- [RFP-019 — On-Chain TWAP Oracle](./RFP-019-twap-oracle.md) (assumes wrapped + external assets as priced collateral) +- [RFP-020 — RedStone Off-Chain Oracle Adaptor for LEZ](./RFP-020-redstone-oracle-adaptor.md) + (reference for in-program proof verification cost measurement) +- [RFP-021 — Trustless Ethereum State Attestation for LEZ](./RFP-021-ethereum-state-attestation.md) + (delivers the verification of finalised Ethereum state that the inbound mint + path consumes) +- [RFP-023 — Native Gas Token Bridge for LEZ](./RFP-023-gas-token-bridge.md) + (the reverse direction, with LEZ as the vault, built on this RFP's patterns) +- [LP-0012: Event/Log mechanism for LEZ](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0012.md) +- [LP-0013: Token program improvements: authorities](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0013.md) +- [RISC0 — Zero-Knowledge VM](https://github.com/risc0/risc0) +- [Zisk — RISC0 Proof Generation](https://github.com/risc0/zisk) (reference + implementation for proof generation) +- [Chainalysis — Cross-Chain Bridge Hacks](https://www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/) + (bridge-hack loss data) + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, please use +**Discussions**. diff --git a/appendix/bridges-and-wrapped-tokens.md b/appendix/bridges-and-wrapped-tokens.md new file mode 100644 index 00000000..877b3c28 --- /dev/null +++ b/appendix/bridges-and-wrapped-tokens.md @@ -0,0 +1,482 @@ +# Appendix: Bridges and Wrapped Tokens + +This appendix surveys the ecosystem context behind +[RFP-022](../RFPs/RFP-022-wrapped-erc20.md), a privacy-preserving wrapped ERC-20 +bridge for LEZ, in two parts. The first and larger part surveys major +cross-chain bridge exploits, classifies their root causes, and sources the loss +figures relevant to RFP-022's claim that bridges are the most-attacked category +of DeFi infrastructure, and to its design choice to eliminate signer/validator +trust while still treating verification-logic correctness and upgrade-key +custody as first-order risks. The second, shorter part sources RFP-022's +stablecoin market-size claim, which motivates the specific tokens (USDC, USDT, +DAI, WETH) the RFP proposes wrapping first. + +## Summary Table + +Ordered by date. USD figures are as reported at or near the time of the hack; +where sources disagree, a range is given (see per-hack sections for detail). + +| Hack | Date | Amount (USD, as reported) | Root cause category | Source | +| ------------------------------ | ---------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | --------- | +| Poly Network | 10 Aug 2021 | ~$611M (range $600M-$613M) | (b) Verification/access-control bug (self-granted authority) | [7][8][9] | +| THORChain (Bifrost/ETH Router) | 15 & 22 Jul 2021 | ~$8M + ~$8M (two incidents) | (b) Smart contract / verification logic bug | [27][28] | +| Qubit Finance (QBridge) | 27-28 Jan 2022 | $80M | (b) Smart contract / verification logic bug | [23][24] | +| Wormhole | 2 Feb 2022 | ~$325M (range $320M-$326M) | (b) Smart contract / verification logic bug | [4][5] | +| Meter.io (Meter Passport) | 5 Feb 2022 | ~$4.3M-$4.4M | (b) Smart contract / verification logic bug | [25][26] | +| Ronin Network / Axie Infinity | 23 Mar 2022 | ~$625M (range $540M-$625M) | (a) Validator/multisig key custody compromise | [1][2] | +| Harmony Horizon Bridge | 23 Jun 2022 | ~$100M | (a) Validator/multisig key custody compromise | [20][21] | +| Nomad | 1 Aug 2022 | ~$190M (range $190M-$200M) | (b) Verification logic bug, introduced via a legitimate upgrade | [6][10] | +| BNB Bridge / BSC Token Hub | 7 Oct 2022 | ~$570M minted (range $566M-$586M); ~$100M-$110M actually moved off-chain | (b) Smart contract / verification logic bug | [17][18] | +| Multichain | 6-7 Jul 2023 | ~$125M-$126M | (c) Admin/custody key compromise (MPC custody, single controlling party) | [14][15] | +| Orbit Chain | 31 Dec 2023 | ~$81M-$82M (range $81M-$86M) | (a) Validator/multisig key custody compromise (disputed; operator cites insider/infrastructure compromise) | [29][30] | + +## Per-Hack Detail + +### Poly Network (10 August 2021) + +Poly Network's `EthCrossChainManager` contract accepted attacker-supplied +cross-chain transaction data and could invoke arbitrary functions via +`_executeCrossChainTx`, including privileged functions on the +`EthCrossChainData` contract that `EthCrossChainManager` owned. The attacker +crafted a call that invoked `EthCrossChainData.putCurEpochConPubKeyBytes()`, a +function intended only for legitimate keeper-rotation consensus, through this +unintended call chain, reassigning the "keeper" (the address authorized to +approve cross-chain fund releases) to an address they controlled. They then used +that self-granted authority to authorize withdrawals across Ethereum, BNB Smart +Chain, and Polygon. SlowMist's and BlockSec's independent analyses both state +explicitly that this was not a leaked private key [8][9]. Reported losses range +from $600.3M to $613M depending on the token-price snapshot used across the +three affected chains; $611M is the most frequently cited figure [7]. Nearly all +funds were returned by the attacker within about two weeks. + +This sits at the boundary between categories (b) and (c): no credentials were +compromised, so it is fundamentally an access-control/verification bug, but its +*effect* (self-appointing as the sole trusted signer) is functionally equivalent +to what a stolen keeper or governance key would achieve. + +### THORChain Bifrost/ETH Router (15 and 22 July 2021) + +Two separate incidents in the ETH Router bridging component of THORChain, a +cross-chain liquidity network rather than a pure lock-and-mint bridge. In both +cases, attacker-deployed token contracts fed fake metadata to the router, +tricking it into refunding real assets for fake or manipulated deposits. +THORChain's own post-mortem confirms both as router logic bugs, not key +compromises [27][28]. Losses were approximately $8M in each incident. Included +here as a borderline case: it is a cross-chain bridging component being +exploited via a logic bug, but THORChain's overall architecture is an +AMM/liquidity network, not a lock-and-mint bridge in the RFP-022 sense. + +### Qubit Finance / QBridge (27-28 January 2022) + +QBridge exposed a legacy `deposit()` function alongside a newer `depositETH()` +function. The attacker called the legacy function with the ETH resource ID but +supplied zero actual ETH and a malformed token address; the contract's +transfer-verification logic did not check that a real transfer had occurred, so +it emitted the same deposit event the BSC-side relayer used to mint qXETH. This +minted 77,162 qXETH against no real collateral, which the attacker then used as +loan collateral to drain approximately $80M in ETH, BTC-B, stablecoins, and +other tokens [23][24]. A pure smart contract logic bug; no key or upgrade +mechanism was involved. + +### Wormhole (2 February 2022) + +The Solana-side Wormhole program used a deprecated helper, +`load_instruction_at`, to verify that a `secp256k1_program` +signature-verification instruction preceded a mint instruction. The deprecated +function did not check that the "instructions sysvar" account passed to it was +Solana's genuine sysvar account. The attacker supplied a spoofed sysvar account +pre-populated with fabricated data mimicking a valid signature-verification +instruction, and the program accepted this forged input as proof that the +required guardian signatures had validated a Verified Action Approval (VAA). +This let the attacker mint 120,000 wETH on Solana with no real ETH backing on +Ethereum [4][5]. USD figures range from $320M to $326M depending on the ETH +price used at time of reporting; the token amount (120,000 wETH) is the more +stable figure. The bug was patched by switching to +`load_instruction_at_checked`. This is a verification-logic bug in +already-deployed program code, unrelated to any contract upgrade or key +compromise. + +### Meter.io / Meter Passport (5 February 2022) + +Meter Passport's auto-wrap/unwrap convenience feature for native gas tokens +(ETH, BNB) did not properly restrict direct interaction with the wrapped ERC-20 +contracts, nor verify that a matching real value transfer had occurred, letting +the attacker mint WETH/WBNB without depositing real collateral [25][26]. The +direct loss to Meter was approximately $4.3M-$4.4M (1,391 ETH and 2.74 BTC), +with an additional ~$3.3M cascading loss at the dependent lending protocol +Hundred Finance. Same general failure family as Qubit: an event-driven relayer +trusting an event that did not correspond to a real transferred value. + +### Ronin Network / Axie Infinity Bridge (23 March 2022) + +Ronin's bridge required 5-of-9 validator signatures to authorize withdrawals. +The attacker compromised five validator keys: four Sky Mavis-run validators via +a single senior engineer, who was compromised through a fake LinkedIn job offer +whose "offer" PDF carried spyware, giving the attackers a foothold into Sky +Mavis's infrastructure and its four validator keys; and a fifth signature from +the third-party Axie DAO validator, obtained not by directly breaching Axie DAO +but because Axie DAO had granted Sky Mavis a temporary gas-fee allowlist +delegation in November 2021 (to handle demand load) that was never revoked. The +attackers' already compromised systems used this still-active delegated +permission to sign on Axie DAO's behalf [1][2]. Reported losses are 173,600 ETH +plus 25.5M USDC, most commonly valued at $625M at the time; figures as low as +$540M appear in some contemporaneous reporting depending on the ETH price used. +The exploit occurred on 23 March 2022 and was discovered on 29 March 2022, when +a user's 5,000 ETH withdrawal failed. This is a direct compromise of validator +signing keys that custody bridge funds via multisig consensus; no contract bug +or upgrade mechanism was involved. Ronin suffered a second, unrelated incident +in August 2024 via an authorized-upgrade bug (see "Upgrade-key compromise: what +the evidence shows," below). + +### Harmony Horizon Bridge (23 June 2022) + +The Ethereum-side Horizon bridge used a multisig requiring only two signatures +(commonly cited as 2-of-5) to authorize withdrawals. Per Harmony's own incident +summary, attackers ran a multi-stage intrusion: phishing and social engineering +against developers to plant malware, which gave visibility into internal +communications and non-public bridge infrastructure code, culminating in +backdoor access to privileged servers where keys were generated or decrypted on +the fly. This gave the attackers enough plaintext private keys to meet the +two-signature threshold and authorize eleven fraudulent withdrawal transactions +[20][21]. Losses were approximately $100M across ETH, WBTC, USDC, USDT, BUSD, +and other tokens. The attack was later attributed by Elliptic and the FBI to the +Lazarus Group, with funds laundered via Tornado Cash. A direct compromise of +fund-movement signing keys; no smart contract logic was exploited. + +### Nomad (1 August 2022) + +During a routine, authorized contract upgrade on 21 April 2022, Nomad's team +initialized the `Replica` contract's trusted-root storage by calling +`initialize()` with `0x00` set as an acceptable root. In Solidity, unset mapping +entries also default to `0x00`. Because the `process()` function treated any +message whose root matched an entry in the acceptable-root mapping as valid, and +`0x00` was both the deliberately "trusted" value and the default value for an +unproven message, every unproven message hash was automatically treated as +proved. This let the first attacker submit an arbitrary spoofed message to drain +funds; because the exploit calldata was trivially copy-pasteable (swap the +recipient address), it triggered a chaotic free-for-all involving roughly 960 +transactions from hundreds of opportunistic addresses on 1 August 2022 [6][10]. +Losses are commonly cited at $190M, with some sources rounding to $200M +depending on how traced/recovered funds are accounted for. + +No upgrade key or admin key was stolen or misused by an external attacker. The +vulnerability was introduced by Nomad's own team through a legitimate, +authorized upgrade with a catastrophic initialization error — a distinct failure +mode from a compromised or misused upgrade key. See "Upgrade-key compromise: +what the evidence shows," below, for why this distinction matters. + +### BNB Bridge / BSC Token Hub (7 October 2022) + +The BSC Token Hub validated cross-chain messages using an IAVL Merkle proof +scheme. The verification code failed to enforce that a proof node had no forged +"right" child: it computed the root hash using only the "left" field and never +checked for an injected "right" attribute. The attacker took a legitimate +historical proof, injected a crafted "right" node containing a forged payload +claiming a deposit that never happened, and the verifier's root-hash comparison +passed because the malicious right-child data was never included in the hash it +validated against. This let the attacker forge two withdrawal proofs and mint +1,000,000 BNB each (2,000,000 BNB total) with no real backing deposit [17][18]. +This is a pure verification-logic bug (the BNB Chain team named it +"Dragonfruit"); no keys were stolen or misused. The minted amount is commonly +valued at $566M-$586M at the time (~$570M is the most frequently cited +midpoint); of that, only about $100M-$110M was actually moved off-chain before +validators halted the network roughly 90 minutes after the exploit began, with +about $7M frozen immediately and the remainder effectively immobilized once the +attacker's address was blacklisted. + +### Multichain (6-7 July 2023) + +Multichain used an MPC (multi-party computation) custody scheme for bridge +funds. Multichain's CEO, Zhaojun He, was reportedly detained by Chinese police +in Kunming on 21 May 2023, roughly six weeks before large, unauthorized outflows +began. Outflows occurred in waves starting 6-7 July 2023: approximately $58M in +USDC, 1,023.8 WBTC, and 7,214 wETH left the Fantom bridge contract within 30 +minutes, followed by smaller outflows from Dogechain and Moonriver bridge +contracts. Multichain's own team stated they had lost access to the MPC node +servers and could not reach Zhaojun after his arrest [14]. No smart contract +vulnerability has been identified; security-firm analysis states the pattern +does not obviously relate to any previously audited vulnerability. Total losses +are commonly cited at $125M-$126M. A Singapore High Court ruling, in a suit +brought by Fantom against Multichain, found the breach was possible because +Zhaojun held ultimate privileges and control over the custodied assets, though +the court declined to find that he or Multichain actually diverted the funds +[15]; causation remains legally unresolved even though centralized operational +control over the MPC custody scheme is established. This is best classified as +an admin/custody key compromise: the MPC key shares functioned as the +operational custody mechanism for bridge funds, and a single controlling party +(or someone with access to his systems) retained effective unilateral control, +undermining the "multi-party" security assumption the scheme depended on. + +### Orbit Chain (31 December 2023) + +Independent security researchers and Rekt.news attributed this exploit to +compromise of 7-of-10 multisig signer keys on Orbit's Ethereum vault, likely via +social engineering [29]. Orbit's developer, Ozys, published an official +statement on 25 January 2024 explicitly denying both a smart contract +vulnerability and the theft of a validator key, instead attributing the root +cause to a former CISO who "arbitrarily changed firewall policies" shortly +before departing the company (resigned 6 December, exploit occurred 31 December) +[30] — implying insider sabotage or infrastructure compromise rather than direct +key theft. The two accounts are not fully mutually exclusive: a compromised +firewall could be the vector through which signer keys were exposed. This is a +genuine, unresolved disagreement between independent researchers and the +project's own statement, noted here rather than resolved. Losses are reported in +the $81M-$86M range, with $81.5M the most commonly cited figure. No mention in +any source of an upgradeable proxy or upgrade key; the funds were held directly +in a multisig-controlled vault. + +## Upgrade-key compromise: what the evidence shows + +RFP-022 treats an upgradeable verifier contract's *upgrade key* as a key-custody +attack surface of the same kind as a validator or multisig key, one layer +removed: whoever holds the upgrade key can substitute the verification logic +itself, rather than directly signing a fraudulent withdrawal. This is a distinct +category from every hack tabulated above, none of which involved an upgrade key +being stolen or misused by an external attacker. Two related but distinct +patterns emerge from the historical record, and they should not be conflated: + +**Pattern A: a legitimate, authorized upgrade introduces a catastrophic bug.** +No key is stolen; the team that legitimately controls the upgrade key exercises +it correctly, but the new logic is broken. Nomad (above) is the clearest bridge +example: a routine upgrade set a trusted root to a value that collided with the +default "unproven" value. A second, later example from the same project family +is instructive: Ronin suffered a second, unrelated incident in August 2024, +distinct from the March 2022 validator-key compromise. During a `BridgeManager` +contract upgrade, the team skipped calling `initializeV3()`, leaving an internal +`_totalOperatorWeight` value at zero, which disabled the minimum-vote-weight +check and let a single signature pass verification where several should have +been required. An MEV bot found the bug and withdrew $12M, later returned as a +whitehat disclosure for a $500K bounty [19]. Both cases show that the +bug-introduction risk from a mutable, upgradeable verifier is real and has +caused (Nomad) or nearly caused (Ronin 2024) major losses, even absent any +attacker gaining control of the upgrade key itself. + +**Pattern B: an attacker manufactures upgrade or governance authority through a +separate bug**, rather than stealing the legitimate key outright. Audius (July +2022, a DeFi governance protocol, not a bridge) is the clearest example: a +storage-slot collision between the proxy's admin slot and OpenZeppelin's +`Initializable` flag let an attacker call `initialize()` again on an +already-initialized proxy and seize governance control, which they then used to +push a malicious governance action draining approximately $6M in AUDIO tokens +[11][12]. Wormhole had a near-miss of the same kind: an uninitialized UUPS proxy +would have let an attacker call `initialize()`, set themselves as guardian, and +push a malicious upgrade; this was caught and responsibly disclosed through +Wormhole's bug bounty program before any exploitation, with a $10M bounty paid +and no funds lost [13]. Poly Network (above) is a bridge-specific variant of +this same pattern: no key was stolen, but a verification bug let the attacker +self-grant an authority (the "keeper") that functions as the bridge's trusted +signer set, achieving an effect equivalent to a stolen governance key without +stealing one. + +**No documented case of a completed bridge hack via a genuinely stolen or +phished upgrade key was found.** The clearest examples of an upgrade key or +admin key being directly compromised and used to push malicious logic are +outside the bridge category: PAID Network (March 2021), where an attacker +compromised the single private key controlling proxy upgrade rights, upgraded to +malicious logic, and minted approximately 59.5M tokens for a loss of roughly $3M +[16]; and Wasabi Protocol (April 2026), a perpetuals protocol where an attacker +compromised the deployer EOA holding sole admin rights (no multisig or +timelock), granted itself an admin role, and executed unauthorized upgrades on +vault proxies, draining approximately $4.5M-$5.5M across three chains. Both are +DeFi protocols, not cross-chain bridges. Security-firm commentary (Trail of +Bits' 2020 review of Aave's upgradeability, and general framing from Immunefi +and OpenZeppelin) treats post-deployment upgrade mechanisms as a +disproportionate source of protocol losses as a general class, but without a +bridge-specific incident list to cite. + +The practical reading for RFP-022's argument: the *category* of risk (a mutable +verifier controlled by a key that can swap in malicious or broken logic) is +real, attested by security-firm framing, and has caused actual bridge losses +through Pattern A (a legitimate upgrade shipping a bug, Nomad and Ronin 2024) +and a bridge-specific near-miss of Pattern B (Wormhole's uninitialized proxy, +caught before exploitation). It has not, in the documented record, caused a +bridge loss through the narrower scenario of an attacker stealing an upgrade key +outright, though that exact pattern has occurred in non-bridge DeFi (PAID +Network, Wasabi Protocol). An immutable program with an explicit migration path +removes the upgrade key from the attack surface entirely, closing off both +patterns rather than only the one with a clean historical precedent. + +## Root-cause breakdown + +Excluding THORChain (a borderline case, not a lock-and-mint bridge in the +RFP-022 sense) and treating Poly Network and Multichain per their categorization +above, the ten core hacks in the summary table break down as follows by dollar +value (approximate, using the midpoint of any reported range): + +- **(a) Validator/multisig key custody compromise:** Ronin (~$625M), Harmony + Horizon (~$100M), Orbit Chain (~$81.5M, disputed). Subtotal: **~$806.5M**. +- **(b) Smart contract / verification logic bug:** Wormhole (~$323M), Nomad + (~$190M), BNB Bridge (~$576M minted, ~$105M actually exfiltrated), Qubit + Finance (~$80M), Meter.io (~$4.35M), Poly Network (~$611M, boundary case). + Subtotal using minted/at-risk BNB Bridge figure: **~$1.784B**; using the + amount actually moved off-chain for BNB Bridge instead: **~$1.313B**. +- **(c) Admin/governance key compromise:** Multichain (~$125.5M, boundary case + with (a) given MPC custody). Subtotal: **~$125.5M**. + +This does not cleanly reproduce a "half key custody, half verification bugs" +split in dollar terms across this specific set: by these figures, +verification-logic bugs account for a larger share of gross value at risk than +key-custody compromises, driven heavily by the BNB Bridge minted amount and Poly +Network's near-$611M figure, both of which are boundary cases (BNB Bridge +because most of the minted value was never actually moved off-chain; Poly +Network because the bug's effect mimicked a stolen governance key without one +being stolen). If Poly Network is instead counted toward key custody (its effect +being equivalent to a stolen keeper key) and BNB Bridge's actually-exfiltrated +figure is used rather than its minted figure, category (a) plus Poly Network's +$611M would dominate instead. The underlying point RFP-022 makes — that key +custody is a large but not exclusive source of bridge losses, and +verification-logic bugs are a comparably large source — holds directionally +across every reasonable way of drawing the boundary cases; a precise 50/50 split +should not be asserted as an exact figure, because it depends heavily on how BNB +Bridge's minted vs. exfiltrated amount and Poly Network's boundary case are each +counted. + +## Chainalysis figures: what the primary sources actually say + +RFP-022 cites Chainalysis for the claim that over $2B was stolen from +cross-chain bridges in 2022, representing 64% of that year's DeFi hacking +losses. Chainalysis in fact published two separate figures, from two separate +reports, that are often conflated: + +- **"Cross-Chain Bridge Hacks Emerge as Top Security Risk"** (2 August 2022) + \[3\]: "Chainalysis estimates that $2 billion in cryptocurrency has been + stolen across 13 separate cross-chain bridge hacks... Attacks on bridges + account for 69% of total funds stolen in 2022 so far." This is a + **partial-year** figure (through early August 2022), and the 69% is a share of + **all** cryptocurrency theft in that period, not specifically of DeFi losses. +- **"2022 Biggest Year Ever for Crypto Hacking"** (1 February 2023) \[3\]: "DeFi + protocols as victims accounted for 82.1% of all cryptocurrency stolen by + hackers — a total of $3.1 billion... And of that $3.1 billion, 64% came from + cross-chain bridge protocols specifically." This is the **full-year** figure, + and the 64% is a share of **DeFi-specific** losses ($3.1B), not of all crypto + theft. 64% of $3.1B is approximately $1.98B, close to but not identical to the + earlier $2B figure, which came from a different, partial-year, + differently-denominated report. + +Both figures are directionally consistent and both support the underlying claim +that bridges were the single largest category of DeFi hacking losses in 2022. +But the $2B dollar figure and the 64% percentage, as commonly paired in +secondary reporting (including news aggregation that RFP-022's figure likely +traces to), actually come from two different Chainalysis reports measuring +different populations over different time windows, not from a single, internally +consistent statistic. The more defensible citation is the February 2023 report's +64%-of-2022-DeFi-losses figure on its own, or the August 2022 report's +$2B/69%-of-total-crypto-theft figure on its own, rather than pairing the two +numbers as if from one source. + +### Trend since 2022 + +Chainalysis does not appear to publish a recurring, directly comparable +bridge-hack-specific percentage in its subsequent annual reports; coverage +shifted toward broader categories such as private-key compromises and +centralized-exchange hacks, and toward bridges as a money-laundering conduit +(chain-hopping) rather than as the primary attack vector. Total crypto hacking +losses (all categories, not bridge-specific) reported by Chainalysis in +subsequent years: + +- **2023:** approximately $1.7B, down roughly 54% year-over-year [31]. +- **2024:** approximately $2.2B, up roughly 21% year-over-year [32]; the largest + bridge-specific incident that year was Orbit Chain (~$81.8M), a small fraction + of the total. +- **2025 (mid-year):** more than $2.17B stolen by mid-July 2025, already + exceeding all of 2024, though dominated by the Bybit exchange hack (~$1.5B, a + private-key compromise, not a bridge exploit) rather than by bridge-specific + losses [33]. + +The overall pattern is a marked decline in bridge hacks specifically as a share +of total DeFi/crypto losses since the 2022 peak, even as total crypto theft has +fluctuated and, by mid-2025, exceeded 2022 levels again driven by other +categories (notably exchange and private-key compromises). + +## Stablecoin Market Context + +RFP-022 cites USDT and USDC together holding "over 80%" of a stablecoin market +"above $300B in mid-2026" as the rationale for prioritising those two assets +(alongside DAI and WETH) as the bridge's first wrapped tokens. DefiLlama tracks +total stablecoin market capitalisation at approximately $310B-$313B through +mid-2026, having peaked above $321B earlier in the year before shedding roughly +$10B by late July [34][35]. The "above $300B" framing is accurate as a floor, +though it understates the market by omitting the more precise $310B+ figure +available from the same tracker. + +Tether (USDT) is the largest stablecoin by a wide margin, with a market cap of +approximately $183.4B and roughly 59-64% of total stablecoin supply depending on +the exact date sampled [36][37]. Circle's USDC is second, at approximately +$72B-$75B, roughly 23-24% of supply [37][38]. Combined, USDT and USDC hold +approximately 89% of total stablecoin market capitalisation as of early August +2026 [36][37] — comfortably clearing RFP-022's "over 80%" claim rather than +merely meeting it. + +Supply share is not the same claim as settlement dominance, and the two should +not be conflated. On supply, USDT leads by a wide margin. On on-chain DEX +settlement volume specifically, the picture has shifted materially during 2026: +USDC accounted for roughly 70-80% of adjusted stablecoin transaction volume in +H1 2026, ahead of USDT's roughly 25%, a reversal from historical patterns where +USDT dominated volume [39][40]. Curve and Uniswap remain the primary venues for +USDC/USDT pairs, and stablecoin swaps make up the majority of DEX trading volume +on Ethereum [39]. On lending markets, Aave, the largest lending venue by +deposits, reportedly holds an 80%+ share of USDT and USDC deposits/borrows on +Ethereum, with stablecoin pools forming the protocol's largest liquidity base +[41]. Taken together, this supports RFP-022's framing that USDT and USDC are the +settlement asset most DeFi money markets and DEXes actually run on, though the +volume and collateral-share figures are drawn from secondary market trackers and +platform-level reporting rather than a single authoritative cross-protocol +study, and should be read as directionally strong rather than precisely +measured. + +## References + +01. [Halborn — Explained: The Ronin Hack (March 2022)](https://www.halborn.com/blog/post/explained-the-ronin-hack-march-2022) +02. [Ronin/Sky Mavis — Back to Building: Ronin Security Breach](https://roninchain.com/blog/posts/back-to-building-ronin-security-breach-6513cc78a5edc1001b03c364) +03. [Chainalysis — Cross-Chain Bridge Hacks Emerge as Top Security Risk](https://www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/) + (2 Aug 2022, partial-year, $2B/69%-of-total-theft figure); see also + [Chainalysis — 2022 Biggest Year Ever for Crypto Hacking](https://www.chainalysis.com/blog/2022-biggest-year-ever-for-crypto-hacking/) + (1 Feb 2023, full-year, 64%-of-DeFi-losses figure) +04. [Halborn — Explained: The Wormhole Hack (February 2022)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) +05. [CertiK — Wormhole Bridge Exploit Incident Analysis](https://www.certik.com/blog/wormhole-bridge-exploit-incident-analysis) +06. [Immunefi — Hack Analysis: Nomad Bridge, August 2022](https://medium.com/immunefi/hack-analysis-nomad-bridge-august-2022-5aa63d53814a) +07. [Halborn — Explained: The Poly Network Hack (August 2021)](https://www.halborn.com/blog/post/explained-the-poly-network-hack-august-2021) +08. [SlowMist — The Root Cause of Poly Network Being Hacked](https://slowmist.medium.com/the-root-cause-of-poly-network-being-hacked-ec2ee1b0c68f) +09. [BlockSec — The Initial Analysis of the PolyNetwork Hack](https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a) +10. [Halborn — The Nomad Bridge Hack: A Deeper Dive](https://www.halborn.com/blog/post/the-nomad-bridge-hack-a-deeper-dive) +11. [Audius — Audius Governance Takeover Post-Mortem](https://blog.audius.co/article/audius-governance-takeover-post-mortem-7-23-22) +12. [ChainLight — Audius Variant Scanner: Scanning Storage Collisions Between Ethereum Contracts](https://blog.chainlight.io/en-audius-variant-scanner-scanning-storage-collisions-between-ethereum-contracts-4d2d64b77566) +13. [Immunefi — Wormhole Uninitialized Proxy Bugfix Review](https://immunefi.com/blog/bug-fix-reviews/wormhole-uninitialized-proxy-bugfix-review/) +14. [Halborn — Explained: The Multichain Hack (July 2023)](https://www.halborn.com/blog/post/explained-the-multichain-hack-july-2023) +15. [DL News — Singapore Court Ruling Fuels View Multichain Hack Was Inside Job](https://www.dlnews.com/articles/defi/singapore-court-fuels-view-multichain-hack-was-inside-job/) +16. [Halborn — Explained: The PAID Network Hack (March 2021)](https://www.halborn.com/blog/post/explained-the-paid-network-hack-march-2021) +17. [Halborn — Explained: The BNB Chain Hack (October 2022)](https://www.halborn.com/blog/post/explained-the-bnb-chain-hack-october-2022) +18. [Immunefi — Hack Analysis: Binance Bridge, October 2022](https://immunefi.com/blog/bug-fix-reviews/hack-analysis-binance-bridge-october-2022/) +19. [Halborn — Explained: The Ronin Network Hack (August 2024)](https://www.halborn.com/blog/post/explained-the-ronin-network-hack-august-2024) +20. [Halborn — Explained: The Harmony Horizon Bridge Hack](https://www.halborn.com/blog/post/explained-the-harmony-horizon-bridge-hack) +21. [Harmony Community Forum — Summary of the Horizon Bridge Incident](https://talk.harmony.one/t/summary-of-the-horizon-bridge-incident/20990) +22. [Elliptic — The Harmony Horizon Bridge Hack](https://www.elliptic.co/resources/harmony-horizon-bridge-hack) +23. [Halborn — Explained: The Qubit Hack (January 2022)](https://www.halborn.com/blog/post/explained-the-qubit-hack-january-2022) +24. [SlowMist — Our Analysis of the $80M Qubit Finance Exploit](https://slowmist.medium.com/our-analysis-of-the-80m-qubit-finance-exploit-b0f272cd8c25) +25. [Halborn — Explained: The Meter.io Hack (February 2022)](https://www.halborn.com/blog/post/explained-the-meter-io-hack-february-2022) +26. [Cointelegraph — Latest DeFi Bridge Exploit Results in $4.4M Losses for Meter](https://cointelegraph.com/news/latest-defi-bridge-exploit-results-in-4-4m-losses-for-meter) +27. [Halborn — Explained: The THORChain Hack (July 2021)](https://www.halborn.com/blog/post/explained-the-thorchain-hack-july-2021) +28. [THORChain — Post-Mortem: ETH Router Exploits 1 & 2, and Premature Return to Trading](https://medium.com/thorchain/post-mortem-eth-router-exploits-1-2-and-premature-return-to-trading-incident-2908928c5fb) +29. [Rekt.news — Orbit Bridge Rekt](https://rekt.news/orbit-bridge-rekt) +30. [Orbit Chain — Official Statement Regarding Orbit Bridge Exploit](https://medium.com/orbit-chain/official-statement-regarding-orbit-bridge-exploit-551928f3dc52) +31. [Chainalysis — Stolen Crypto Falls in 2023](https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2024/) +32. [Chainalysis — $2.2 Billion Stolen in Crypto in 2024](https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2025/) +33. [Chainalysis — 2025 Crypto Crime Mid-Year Update](https://www.chainalysis.com/blog/2025-crypto-crime-mid-year-update/) +34. [DefiLlama — Stablecoins](https://defillama.com/stablecoins) — total + stablecoin market cap and per-issuer breakdown, tracked live +35. [Bitcoin Foundation — Stablecoin Market Cap Tops $321B, Extending 2026 Growth](https://bitcoinfoundation.org/news/stablecoin-news/stablecoin-market-cap-tops-321b/) +36. [CoinLaw — Tether Statistics 2026](https://coinlaw.io/tether-statistics/) — + USDT market cap and supply-share figures, early August 2026 +37. [The Motley Fool — Which Stablecoins Are the Largest and Most Popular](https://www.fool.com/research/largest-stablecoins/) + — USDT/USDC combined market-share figure +38. [USDC.org — USDC Supply Stats](https://usdc.org/stats) — USDC circulating + supply and market cap +39. [KuCoin — USDC Accounts for 70% of Adjusted Stablecoin Volume in H1 2026](https://www.kucoin.com/news/flash/usdc-accounts-for-70-of-adjusted-stablecoin-volume-in-h1-2026) +40. [CoinDesk — Circle's USDC Is Leaving Tether Behind in the Stablecoin Volume Race](https://www.coindesk.com/business/2026/07/06/circle-s-usdc-is-leaving-tether-behind-in-the-stablecoin-volume-race) +41. [Aave — Aave Is Infrastructure for Scaling Stablecoins](https://aave.com/blog/stablecoin-infrastructure) + — Aave stablecoin deposit/borrow share commentary + +______________________________________________________________________ + +*This appendix was prepared to support RFP-022. For clarification or additions, +please use the RFP repository Discussions.* diff --git a/appendix/ethereum-light-client-ecosystem.md b/appendix/ethereum-light-client-ecosystem.md new file mode 100644 index 00000000..3438563b --- /dev/null +++ b/appendix/ethereum-light-client-ecosystem.md @@ -0,0 +1,312 @@ +# Appendix: Ethereum Light Client Ecosystem + +This appendix surveys the production zk light-client implementations relevant to +[RFP-021](../RFPs/RFP-021-ethereum-state-attestation.md), a trustless Ethereum +state attestation primitive for LEZ. It exists to source one specific claim in +that RFP: that a **permissionless operator advancing shared on-chain +light-client state** is an established, audited, production pattern rather than +a novel design, and that the trust properties of that pattern are well +understood. + +The survey covers what each implementation does, who is permitted to advance the +on-chain state, what the resulting trust model is, and what a LEZ implementation +can reuse. It deliberately includes one implementation that **restricts** update +submission, because the contrast is the clearest evidence that +permissionlessness is a deployment choice rather than an automatic consequence +of using zero-knowledge proofs. + +## The pattern + +Every implementation surveyed here decomposes the problem the same way. + +Verifying that an Ethereum fact is true requires two things: proving that a +block header is a finalised header of the canonical chain, and proving that some +piece of state is included under that header. The first is expensive, involving +BLS12-381 aggregate signature verification over sync-committee signatures and +the verification of committee handoffs across sync-committee periods. The second +is comparatively cheap, being Merkle-Patricia path verification. + +The two are also asymmetric in another way. Header finality is a fact about +Ethereum that every consumer needs and no consumer needs privately. Inclusion is +specific to the consumer's own transaction. + +That asymmetry drives the architecture: + +1. An **operator** runs off-chain. It follows the beacon chain, generates a + zero-knowledge proof that a light-client finality update is validly signed by + the sync committee, and submits that proof to a contract on the destination + chain. Committee handoffs are proven the same way. +2. A **contract** on the destination chain verifies the proof and stores the + resulting verified state: the current sync committee, and finalised header + roots. The stored state accumulates and is readable by any consumer. +3. A **consumer** submits only a Merkle inclusion proof against a header already + verified in that contract. It performs no signature verification of its own. + +The operator is untrusted. It cannot insert a header the sync committee did not +sign, because the contract verifies the proof on submission; forging a header +would require forging BLS signatures from two thirds of the committee. The only +thing an operator can do is stop, which is a liveness failure rather than a +safety failure, and which is repaired by anyone else running the same operator +software. + +This is the property that makes the operator role viable in a trust-minimised +design, and it is the property RFP-021 requires in Functionality #11. + +## Implementations Surveyed + +| Implementation | zkVM / proof system | Update submission | Audit | Notes | +| ------------------------------------------- | ----------------------- | --------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------- | +| Telepathy (Succinct) | Custom zkSNARK circuits | Permissionless, no access control | **Veridise** | Clearest published statement of the trust model; `step` and `rotate` are `external` with no modifiers | +| SP1 Helios (Succinct) | SP1 zkVM | Permissionless in upstream | **Zellic** | Helios light client compiled into SP1; the modern reference implementation | +| r0vm-helios (Boundless, formerly RISC Zero) | **RISC Zero zkVM** | Follows upstream | **zkSecurity** | Fork of SP1 Helios; the closest existing artefact to a LEZ port target | +| SP1 Helios (Across fork) | SP1 zkVM | **Permissioned**, `UPDATER_ROLE` | **OpenZeppelin** | Deliberate divergence; the counter-example | + +The audits named above are published: Veridise for Telepathy [10], Zellic for +upstream SP1 Helios [11], zkSecurity for r0vm-helios [4], and OpenZeppelin for +the Across fork [5]. The upstream and fork audits are separate engagements +covering different code. + +The [Axelar light client](https://github.com/commonprefix/axelar-light-client) +[8] belongs to the same family but is omitted from the table: it applies the +sync-committee protocol directly rather than through a zkVM, and its repository +does not state an update-submission policy, so it contributes no evidence either +way on the question this survey is asking. + +zkBridge [6] is adjacent but is deliberately not listed above. It follows the +same shared-state shape, an updater contract maintaining verified headers which +applications read with their own Merkle proofs, and its paper claims +permissionless header relay. It is not an Ethereum sync-committee light client, +however: the paper is generic over light-client protocols, its +Ethereum-as-source instantiation is pre-Merge longest-chain proof of work, and +Polyhedra's production deployment runs as a LayerZero DVN attesting per message +rather than as an open header store. It is prior art for the shape, not for the +anchor. + +### Telepathy + +Telepathy states the trust model explicitly, which is why it is the primary +source for the pattern rather than the most current implementation. + +An Operator queries the sync committee for the latest finalised block header and +generates a zkSNARK attesting that enough of the committee signed it, submitted +via `step`. The same Operator handles committee rotation: the sync committee +rotates roughly every 27 hours, and the Operator generates a separate proof +attesting to the correct selection of the next committee, submitted via `rotate` +[1]. + +On permissionlessness, the documentation is unambiguous: "these actors are +completely permissionless. Succinct operates their own version of these actors +so that the user experience of integrating with Telepathy painless, but as all +`LightClient` and `TelepathyRouter` update functions are permissionless (with no +access control), anyone who wishes to can run their own versions of an operator +and relayer can do so" [1]. The `step(...)` and `rotate(...)` functions are +`external` with no access control modifiers. + +The division of labour matters for RFP-021's cost analysis: the Operator bears +the proving cost of consensus verification, and a Relayer separately submits +Merkle proofs validating a message against the header root already stored in the +light client [1]. + +### SP1 Helios + +SP1 Helios is an implementation of a zk Ethereum light client using the Altair +sync committee, combining the Helios light client with the SP1 zkVM [2]. It +verifies the consensus of a source chain inside the execution environment of a +destination chain. + +The operator "keeps an on-chain SP1 Helios light client updated by proving +finalized source-chain consensus updates and submitting them to the +destination-chain SP1 Helios contract" [2]. + +Two commitment modes are relevant to RFP-021's Functionality #3, which requires +inclusion proofs for accounts, storage slots, and event logs. The default mode +commits the finalised light-client state and the execution state root. An +execution-header mode additionally commits the finalised execution block hash +and the finalised execution receipts root [2]. A design that needs receipt and +log proofs requires the receipts root to be committed, which is a concrete +interface decision an applicant will face; the documentation puts the cost of +that mode at approximately 45k additional gas per successful update [2]. + +An end to end attestation spans two proof systems, which is easy to miss when +scoping the work. The sync-committee protocol finalises consensus-layer beacon +headers, whereas the state and receipts roots are execution-layer fields, so the +execution payload header has to be bound into the beacon block body by an SSZ +generalised-index proof over SHA256 before any Merkle-Patricia proof over +keccak256 against those roots carries meaning. The consensus specifications +carry this as `execution_branch` on `LightClientHeader`, checked by +`is_valid_light_client_header` [9]. Implementations that commit already-verified +execution roots on chain, as SP1 Helios does, perform the SSZ half inside the +prover so that a consumer does only the Merkle-Patricia half. + +Event logs are worth a further note. A log is not a trie leaf: the receipts trie +commits whole receipts keyed by transaction index, and there is no logs root in +the block header, only a bloom filter that is a probabilistic hint rather than a +proof. Proving a log therefore means proving its receipt and reading the log out +of it by position. + +### r0vm-helios + +r0vm-helios is the implementation most directly relevant to LEZ, because LEZ +runs on RISC0. + +It is a fork of SP1 Helios that verifies source-chain consensus in the execution +environment of a destination chain, built on the RISC Zero zkVM, and it has +received an independent security audit from zkSecurity, published in the +`risc0/rz-security` repository [3][4]. + +Architecturally it matches the pattern: a consensus RPC endpoint (a beacon node +supporting the Altair light-client protocol methods), an operator that generates +proofs and maintains light-client state, and a destination-chain contract +storing verified consensus data [3]. + +Its existence is why RFP-021 directs applicants to assess reuse rather than +reimplement. An audited RISC Zero implementation of the hardest and most +security-critical component is a materially different starting point from a +blank sheet, and the RFP's Reliability #6 requirement to integrate mature +audited implementations points here. What it is **not** is a drop-in: it targets +EVM destination chains with Solidity contracts, and LEZ is neither. The port +surface, what changes and what carries over unmodified, is an assessment the +applicant must perform and justify. + +### The Across fork: where the pattern is deliberately broken + +Across Protocol maintains a fork of SP1 Helios that makes update submission +permissioned, and it is the most instructive entry in this survey. + +The contract inherits `AccessControlEnumerable` and gates the `update` function +behind an `UPDATER_ROLE`. (The repository has since been restructured and its +`main` branch no longer carries the Solidity contracts; the contract described +here lives on the `audit/march-31-2024` branch, which is what the audit covers.) +Per the OpenZeppelin audit, "the updaters set is immutable, defined at +deployment and cannot be modified afterward, meaning that no new addresses can +be added or removed post-deployment", and "Risk Labs will control the updater +role, ensuring that only trusted entities can submit updates" [5]. No address +holds `DEFAULT_ADMIN_ROLE`, so the role cannot be granted or revoked after +deployment. The audit reached that end state via a finding rather than +confirming a clean intent: code comments said the role "should be admin-less" +while a redundant `_setRoleAdmin` call and contradictory test comments muddied +it, and the superfluous call was subsequently removed [5]. + +Two conclusions follow, and both are load-bearing for RFP-021. + +**Permissionlessness is a choice, not a consequence.** A team can port an +audited zk light client faithfully and still ship a design in which one named +party is the only entity able to advance the state. Nothing about using zk +proofs prevents this. RFP-021 therefore cannot treat the property as implied by +the technology and must require it explicitly. + +**Safety-trustlessness and censorship-resistance are separable.** Even in the +Across design, a rogue updater cannot forge a header; the proof verification +stops that, and safety survives. What is lost is liveness and +censorship-resistance: if Risk Labs stops submitting, or declines to submit, +nobody else can advance the light client, and every consumer stalls. Because the +updater set is immutable, there is no recovery path short of deploying a new +contract. + +That distinction is exactly what RFP-021 asks proposals to state, and this fork +demonstrates that a design can satisfy "no trusted party can forge" while +failing "no party can block". + +## Operator economics + +The pattern raises an obvious question: if nobody is required to run an +operator, why would anyone? + +The answer visible across these deployments is that the cost of advancing the +state is small and the parties who need it advanced are identifiable and +motivated. Submitting an update is a single transaction whose cost is amortised +across every consumer reading the resulting header, and any protocol whose users +depend on fresh headers has a direct incentive to keep them fresh. Succinct runs +operators for Telepathy for user-experience reasons while leaving the role open +to anyone [1]; Across runs its own because its bridge depends on it. + +This is a weaker guarantee than a slashing-backed obligation, and it should be +stated as such: no operator is contractually bound to act. What the design +guarantees is that a stalled light client can be restarted by any party willing +to spend the gas, without permission from anyone, and without any pre-existing +relationship to the deployment. The failure mode is a delay, not a loss, and +recovery does not depend on the party that stopped. + +## Bootstrap trust and deployment multiplicity + +Sync-committee tracking cannot start from nothing. It begins from a +weak-subjectivity checkpoint, a known-good committee, and follows verified +handoffs forward from there. That checkpoint is a one-off trust input at +deployment: everything after it is verified, and nothing before it is. + +Two properties of this bootstrap are worth stating plainly, because they shape +how a deployment should be treated. + +**The checkpoint is independently verifiable.** Unlike a signer set, whose +honesty cannot be checked from outside, a configured checkpoint is a claim about +public Ethereum history that anyone can confirm against public sources before +relying on the deployment. A deployment whose checkpoint is wrong or +unverifiable is detectably so, which is why RFP-021 requires a documented +verification procedure rather than only a configured value. + +**Deployment is not exclusive.** Nothing prevents a second contract being +deployed with a different checkpoint. If a deployment's bootstrap is +mis-configured, or its checkpoint falls outside the weak-subjectivity period, +the remedy is a fresh deployment rather than a governance action over the +existing one. This is a genuine safety valve and it is the reason the primitive +does not need a mutable checkpoint under privileged control. + +It carries a cost that pulls in the opposite direction, and the tension should +be acknowledged rather than resolved by assertion. Fragmenting across +deployments splits the operator incentive, duplicates gas expenditure, and +forces every consumer to decide which contract it trusts. The value of the +shared-state architecture comes precisely from many consumers reading the same +verified headers. A canonical deployment that all consumers converge on is +therefore the intended outcome, with the ability to deploy another treated as a +recovery path rather than a routine expectation. + +## What this implies for a LEZ implementation + +Three consequences carry directly into RFP-021. + +**The cost problem changes shape.** RFP-021's central open question is whether +in-zkVM BLS12-381 verification fits a LEZ transaction budget. Under the shared +state architecture, that cost sits in the operator's submission and is amortised +across every consumer, while a consumer's own transaction contains only Merkle +verification. This does not make the BLS cost disappear, and measuring it +remains a primary deliverable, but it decouples that cost from the per-consumer +budget. + +**The interface is a stored header set, not a per-transaction proof.** A +consumer reads a verified header from shared state and proves inclusion against +it. RFP-021's requirement that verification be callable as a library, so that +verification and the action it authorises are atomic, applies to the inclusion +and predicate steps against already-verified consensus state. + +**Reuse is an assessment, not an instruction.** r0vm-helios is audited, RISC +Zero based, and solves the hardest component. Whether its guest program, its +operator, or only its architecture transfers to LEZ depends on details an +applicant is better placed to evaluate than this specification is. The RFP +points at it as a candidate and requires the assessment to be made and justified +rather than assuming the answer. + +## References + +01. [Telepathy — Off-chain Actors](https://docs.telepathy.xyz/telepathy-protocol/actors); + see also + [Telepathy — Sync Committee Protocol](https://docs.telepathy.xyz/telepathy-protocol/sync-committees) + and + [Telepathy — Smart Contracts](https://docs.telepathy.xyz/telepathy-protocol/contracts) +02. [succinctlabs/sp1-helios](https://github.com/succinctlabs/sp1-helios); see + also [SP1 Helios documentation](https://succinctlabs.github.io/sp1-helios/) +03. [boundless-xyz/r0vm-helios](https://github.com/boundless-xyz/r0vm-helios) +04. [risc0/rz-security — audits](https://github.com/risc0/rz-security/tree/main/audits) + (zkSecurity audit of r0vm-helios) +05. [OpenZeppelin — SP1 Helios Audit](https://www.openzeppelin.com/news/sp1-helios-audit); + see also + [across-protocol/sp1-helios](https://github.com/across-protocol/sp1-helios) +06. [zkBridge: Trustless Cross-chain Bridges Made Practical](https://rdi.berkeley.edu/zkp/uploads/paper.pdf) + (Berkeley RDI) +07. [a16z/helios](https://github.com/a16z/helios) (the underlying Helios light + client) +08. [commonprefix/axelar-light-client](https://github.com/commonprefix/axelar-light-client) +09. [Ethereum Altair light-client specification](https://github.com/ethereum/consensus-specs/tree/master/specs/altair/light-client) +10. [Veridise — Succinct Labs Telepathy audit, 11 March 2023](https://veridise.com/audits-archive/company/succinct/succinct-labs-telepathy-2023-03-11/) +11. Zellic — SP1 Helios audit, 18 to 29 July 2025, published as + `SP1 Helios - Zellic Audit Report.pdf` in + [succinctlabs/sp1-helios](https://github.com/succinctlabs/sp1-helios)