RFP-023: Native Gas Token Bridge for LEZ - #169
Draft
fryorcraken wants to merge 67 commits into
Draft
Conversation
Project style avoids em-dashes and punctuation hyphens in prose; replace the ones in body text with commas, colons, or parentheses depending on the clause (title-line and Resources-list separators are an unrelated repo-wide convention and are left as-is). Also drop the bare "Crucially," opener in the Overview, which asserts importance without adding information. Reformatted with mdformat per repo convention.
The Overview stated verification "rests on RISC0 zero-knowledge proofs of consensus and state, verified in-program on LEZ and via a native precompile on Ethereum." This RFP should specify the required outcome (trustless cryptographic verification) and not dictate the specific proof system or verification mechanism teams must use to achieve it.
Both references to RFP-003 described atomic swaps as a "trustless path" or "bridging" mechanism parallel to wrapping, which is inaccurate: atomic swaps trade assets directly and never mint a wrapped representation on LEZ. Rephrase both mentions (Why This Matters, Out of Scope) to describe atomic swaps as the liquidity route for BTC/XMR/ZEC, distinct in kind from the wrapped-token primitive this RFP defines for ETH/ERC-20.
Addresses review comment https://github.com/logos-co/rfp/pull/158/changes#r3733249831. The previous text quoted RFP-003's unexplained claim that wrapping "is a much simpler construction" without saying why. State the real reasons directly: atomic swaps require an online counterparty, so wrapping is non-interactive; wrapping needs no added infrastructure (counterparty matching); and wrapping produces a genuine LEZ-native token, not just a trade, which is what lets it be composed with AMMs, lending markets, and other DeFi programs.
The opening claimed LEZ DeFi "cannot function" without external collateral and called this RFP a "missing primitive", an overstated framing led by a list of dependent RFPs rather than by why the bridge is needed. Replace with the actual motivation: LEZ's separated public/private state architecture and programmability make private DeFi possible, and bringing in assets from non-private chains like Ethereum has to preserve Logos' sovereignty principle, no custodian, signer, or federation trusted along the way. The dependent-RFP list and the wrapping-vs-swaps comparison remain as supporting detail underneath that framing.
The paragraph was structured around what other RFPs "assume" and "don't specify", an indirect, gatekeeping way to make the point. State it directly instead: wrapped tokens are what let users bring Ethereum assets into LEZ's private DeFi, and list the RFPs that DeFi comprises (DEX, lending, stablecoin, and the price feeds that collateralise them), this RFP is the wrapping primitive that feeds all of them.
Make explicit that wrapped tokens bring not just the asset but its already-established market value into LEZ DeFi, usable directly or posted as collateral, since that value transfer is the actual point of wrapping rather than just moving a token between chains.
Replace "A transparent bridge would deanonymise the whole chain" with a section that states the actual expectation: the applicant must consider and document a strategy for reducing linkability between Ethereum and LEZ events, and where a specific form of linkability can't be avoided, document why and what residual correlation remains. The prior framing asserted unlinkability as a hard requirement "of the same standing as solvency", which overstates what a bridge touching a public chain can actually guarantee. Soften the matching Overview paragraph to the same effect so the two sections don't contradict each other.
P1 and P2 previously claimed the adversary "cannot determine" the true
pairing at all, contradicted a few paragraphs later by "What cannot be
hidden", which correctly states that amount and timing are visible on
Ethereum and do correlate. The Privacy Preservation hard requirements
inherited the same overstatement ("no correlation... better than
chance"). Narrow the hard requirement to what the bridge can actually
guarantee: no information other than amount, token, and timing may link
an Ethereum event to its LEZ counterpart. Update the P1/P2 definitions
and their test requirements to match, and cross-reference the amount
mitigation already specified (fixed denominations, Soft Requirement 1).
The passage claimed LEZ "has no path" to bring stablecoin liquidity onto the chain without a wrapped ERC-20 primitive, and that this blocks downstream protocols. This overstates it: a healthy DeFi ecosystem draws on native LEZ assets, wrapped assets, and synthetics together, and wrapping is one strategy among those we want to see implemented, not the exclusive route. Keep the concrete stablecoin market data as the reason wrapping is a worthwhile target, without implying it's the only way collateral reaches the lending protocol and reflexive stablecoin.
The stated "$2.8B stolen since 2022" is not a real Chainalysis figure. The correct, sourced number is over $2B stolen from cross-chain bridges in 2022 alone (64% of that year's DeFi losses), per Chainalysis's 2022 report. Research into the largest bridge hacks (Ronin, Harmony Horizon, Multichain, Wormhole, Nomad, BNB Bridge, Poly Network) shows key-custody compromise explains roughly half of historical losses by value, and bugs in verification logic explain a comparable share, a risk a cryptographic design does not remove on its own. Broaden the rationale accordingly: state the RFP's cryptographic design targets key-custody compromise specifically, call out verification-logic correctness as an equally important risk, and note that an upgradeable verifier contract reintroduces the same key-custody problem via its upgrade key, hence a preference for an immutable program with an explicit migration path.
The two sections stated the same three problems (destination-hiding, amount-correlation, fee-payer-correlation) twice: once as bare problem statements, then again a section later paired with their mitigations. Merge them so each problem and its mitigation appear together, removing the duplicated problem statements. Also add a Bridge Security hard requirement: the verifier (LEZ bridge program and Ethereum vault verification logic) must be deployed as an immutable program with an explicit migration path, not an upgradeable contract. An upgrade key that can silently replace verification logic is a key-custody attack surface of the same kind the RFP's cryptographic design otherwise eliminates. Link the (forthcoming) bridge hack taxonomy appendix from the three places that previously cited the Chainalysis figure inline, including one that still had the incorrect $2.8B number from before that figure was corrected.
The freeze authority can halt new activity but cannot recover funds already at risk or resolve deposits and burns left in-flight if a bug is found in deployed verification logic. Add a Bridge Security hard requirement: proposals must specify a failsafe strategy for this scenario, constrained so it cannot become a backdoor. Recovery must still go through the depositor or burner proving their own entitlement (the same mechanism as an ordinary claim or redemption), not an admin authority identifying and redirecting funds on a user's behalf, must only release funds to the address or account the proof specifies, and must not reach funds beyond what a specific, proven vulnerability put at risk. If no such mechanism is achievable, the proposal must instead document why a failsafe should not be implemented and what happens to affected positions in its absence.
"Stablecoins are the concrete prize" contained an unrelated paragraph about bridge-hack history and this RFP's security posture against it. Give that content its own subsection so each heading matches what it actually discusses.
"Bridges are the most attacked category of infrastructure in DeFi" read as an assertion rather than a heading. Rename to "Bridge risks: hacking" to match the plainer, descriptive heading style used elsewhere.
…tion Both sections opened by restating the same premise (amount and timing are public on Ethereum by construction) before diverging into distinct content: the formal P1/P2 definitions, and the concrete facts plus mitigations. Merge into one section that states the public facts first, then builds the precise P1/P2 requirement on top of them, removing the duplicated framing and the two-section back-reference.
…very "Recover their full bridge position" conflated two different things. Redemption is not stateful in that sense: once minted, a wrapped token is an ordinary LEZ token, and whoever holds it, whether from their own deposit or bought later on an AMM, can burn it to claim the underlying Ethereum asset. The only genuinely stateful recovery need is narrower: a user's own unclaimed deposits and unreleased burns, recoverable from credentials they already hold. Restate Design Rationale's "Loss of access" and Functionality #10 to reflect this distinction instead of implying redemption depends on the original depositor's credentials.
Compress the four-paragraph lead-in and P1/P2 definitions into a tighter statement of the same content: the two public facts folded into one sentence, the hard requirement stated once, and P1/P2 trimmed to their essential claim. No requirement dropped, just restated more directly.
Sources RFP-021's claims about bridge-hack history and stablecoin market size: a summary table and per-hack detail for 11 major bridge exploits with root-cause classification, a dedicated section on whether any bridge hack has involved a stolen upgrade key, a root-cause dollar breakdown, an analysis of the two distinct Chainalysis reports commonly conflated into a single "$2B / 64%" citation, and a stablecoin market-size section verifying the "over 80%" USDT+USDC share and "above $300B" total market cap figures.
The appendix's research (now committed at appendix/bridge-hack-taxonomy.md) surfaced three overstatements in the RFP body: the "$2B / 64%" figure paired two different Chainalysis reports measuring different populations over different time windows; "roughly half... comparable share" implied an even key-custody vs. verification-bug split that doesn't hold cleanly in dollar terms and by some reasonable accounting favours verification bugs; and the upgrade-key paragraph implied bridge hacks from stolen upgrade keys are a documented pattern, when in fact no such case was found, the real documented bridge risk from mutable verifiers is a legitimate upgrade shipping a bug (Nomad, Ronin 2024). Correct the Why This Matters paragraph and Bridge Security requirement #8 to state what the appendix actually supports, without weakening the underlying design conclusion (prefer an immutable program with a migration path), which still holds either way.
The appendix now covers both the bridge-hack survey and the stablecoin market-size sourcing, so the filename and title should reflect the broader scope rather than only the (larger) bridge-hack section. Update the appendix's title and opening paragraph, and all three links to it from RFP-021's body.
…nale The paragraph described a specific implementation (commitment-and- nullifier shielded pool, minting into private LEZ state, permissionless proof anchoring) despite being framed as "orientation, not prescription". This RFP specifies outcomes and required properties, not implementations; proposals choose their own construction. The underlying requirements this paragraph gestured at are already stated as hard requirements elsewhere (Functionality #4 for private-state minting, the P1/P2 properties above for destination-hiding), so nothing is lost by removing the suggested implementation.
"Loss of access" only described the deposit-to-mint window; state the symmetric burn-to-release window explicitly too, matching Functionality #10's existing scope (unclaimed deposits and unreleased burns). State recovery more concretely: a user must recover from their existing wallet seed alone, with no other information. Express a design preference for constructions where the needed claim/entitlement data can be regenerated from on-chain events or state via the user's own keys, over designs that generate 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.
"Trusted for liveness only: able to decline service" implicitly accepted a design where some off-chain party's cooperation is needed at all, which conflicts with the non-interactive protocol this RFP requires (see Why This Matters: a deposit "does not need a counterparty to be online"). Restate the requirement: the protocol should not depend on any specific off-chain participant, and where one is unavoidable (relaying, proving), that role must be permissionless so a single participant declining never blocks the user, generalising the permissionless-relayer pattern already used for the fee-payer mitigation above.
Stating that the vault must measure its own balance increase rather than trust the claimed deposit amount is basic smart-contract hygiene, not something this RFP needs to spell out as a requirement; it only made the sentence longer without adding information. The specific, non-obvious case that does need stating, fee-on-transfer and rebasing tokens breaking this assumption, remains in "Token registry and decimal normalisation".
RISC0 is a genuine, unavoidable dependency on the LEZ side, since LEZ itself runs on RISC0, so LEZ-side proving requirements correctly keep mentioning it. But several places also mandated RISC0-specific constructions (a Groth16 precompile, "this RFP specifies RISC0... not a candidate for alternative proof systems") for the Ethereum-side verification, which is a design choice this RFP has no reason to dictate. Generalize Functionality #3 and #8, Usability #4, the Out of Scope RISC0 bullets, and Platform Dependencies' "RISC0 zkVM" section to state the LEZ-side dependency as fact while leaving the Ethereum-side proof system to the proposal. RFP-021: support public and private LEZ accounts for both mint and burn Functionality #4 and #7 previously mandated private-state-only minting and burning. Change this to a choice: both flows must support a private or a public LEZ account as the destination/source, at the user's choice, rather than forcing private accounts exclusively. Add a new Usability requirement that the mini-app and CLI default to inviting the user toward the private path (pre-selected, public path needs an explicit action), consistent with the existing Privacy Preservation "default configuration must be private" requirement. Update the Platform Dependencies "Private LEZ account state" section to match. RFP-021: require deposits and burns to secretly commit to their destination Add a new Bridge Security hard requirement: a deposit and a burn must each secretly commit to the destination on the other chain, so a claim can only be completed by whoever holds the originating seed, and no information beyond that seed, however it leaks, from the transaction itself, public state, or any party in the flow, can let someone else construct a valid claim. This closes a gap the earlier destination- hiding requirements (Functionality #2, #6) didn't fully cover: hiding a destination from observers is not the same as cryptographically binding the claim to it.
Three cleanups to Functionality: - Removed "the design must not restrict minting/burning to private accounts only" from #4 and #6 (old #4/#7). These clauses only made sense as a diff against the previous private-only wording; stated on their own they're confusing, since nothing established a private-only restriction to argue against. - Removed the old #5 (repeat-claim rejection) entirely, per direction. - Removed "where a burn involves a private account, the burn must not thereby reveal its Ethereum destination" from burn support (old #7): redundant with the destination-hiding requirement on the burn path itself (now #5), and wrongly implied that requirement only applies when burning from a private account, when it applies to every burn. Renumbered Functionality #5 through #18 down to #4 through #17 accordingly, and fixed all eight downstream cross-references across Bridge Security, Soft Requirements, and Platform Dependencies.
Add Soft Requirement 8: an ERC-20 on Ethereum representing a Logos zone's native gas token, where minting it is actually a release of gas token already escrowed on the LEZ side, the inverse of this RFP's primary deposit/mint flow. The goal is letting a user with no existing holdings on the zone acquire gas via the bridge, so they are never blocked from their first transaction. Since this direction has no external market minting new supply on Ethereum (unlike a wrapped external asset), require proposals to either treat it symmetrically to the primary flow and document how the Ethereum-side escrow is funded and replenished, or document why it isn't achievable and what alternative bootstrapping mechanism would be needed instead.
Functionality: - Simplify #7 (Ethereum release): drop the redundant "if the original deposit was ETH" clause and "each burn may be redeemed at most once" restatement. - Delete the old #9 (funded-account / relayer-learns-nothing item); its substance is now folded into Bridge Security. - #11 (registry): replace the sync/divergence language with a plain documentation requirement covering registration changes and delisting. - #14 (fee): "can be charged" instead of "is charged", drop the redundant "no fee mandated on Ethereum" sentence, note the admin can set either fee to zero. - #15/#16 (chain ID, multi-config): rewrite around a precise program-refers-to-contract-refers-to-zone model instead of vague "vault contract... Ethereum mainnet" language that didn't fit the LEZ side and ignored testnets. #16 now allows "same or different pairs" of blockchain programs. Usability: - #1 rewritten around a Logos core module used by multiple Logos ui modules, rather than an SDK. - #2 (mini-app) trimmed to drop build/deployment detail that belongs in Supportability. - CLI item removed from Usability (moved conceptually to Supportability doc-packet requirements). - New #5: the three privacy correlation mitigations (amount, timing, fee payer) must be enabled by default, with a leak indicator and recommended parameters, replacing the narrower anonymity-set-warning item. Supportability: - Testnet wording corrected (LEZ testnet, not devnet/testnet). - Doc packet items reference "the core module" instead of "the SDK". - New deployer doc-packet item, matching the pattern of the SDK and CLI doc-packet items, covering how an entity stands up its own configured deployment. - Figma-designs item removed. - Audit item simplified to "the audit report must be published", dropping the Chainalysis justification aside. - New item requiring the Logos Ethereum core module (with verified proxy features), RPC/target switching in the UI, the Lambda Prize wallet SDK, RFP-001/002 outputs for admin and freeze authorities, compatibility with the existing LEZ token program and ATA derivation, catalog publication, and standard Logos GitHub Actions. Bridge Security: - Removed the standalone "off-chain component must independently derive chain state" item. - Merged the claim-theft-resistance requirement into the malicious- relayer item, since they covered overlapping ground. Platform Dependencies: - Trimmed the LP-0013, "Private LEZ account state", and "RISC0 zkVM" subsections to their core dependency statements. - Moved "Event emission (LP-0012)" from Soft to Hard dependencies, removing the now-empty "Soft dependencies" heading. Out of Scope: removed the BTC/XMR/ZEC, mobile/in-browser proving, and price-feed bullets (now covered elsewhere or no longer needed as exclusions). Renumbered Functionality, Bridge Security, and their downstream cross-references throughout to stay sequential and accurate.
Avoids collision with the numbered items (1., 2., ...) in the FURPS Privacy Preservation requirements list, where "1. P1 must hold under test" read as if P1 meant that item's own number. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PP1/PP2 read as "Privacy Preservation 1/2", colliding with the section name itself, on top of already colliding with that section's own item numbering. Instead of any invented label, the inbound/outbound unlinkability properties are now defined directly as Privacy Preservation items #1 and #2, and every other reference cites them the same way the doc already cites other FURPS items elsewhere (Functionality #2, #5, Supportability #9, etc). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Credit Cryptarchia and Blend alongside LEZ architecture - Note wrapped Bitcoin and synthetics as other strategies under consideration - Require the UI to encourage a submission delay - Drop the "not the only deployment model" hedge; the RFP does mandate admin curation - Remove fee-on-transfer/rebasing rejection as an implementation choice - Drop the RFP-017 comparison and "in the manner of RFP-004" cross-reads - Add Design Rationale: One program pair = one chain pair - Add admin UI to Usability #2 - Move proof-system maturity and CI-green to Reliability - Split Supportability #11 into separate criteria; move dependencies to Platform Dependencies (Logos Ethereum core module, wallet SDK, ATA/token program) - Correct LP-0013 title and mark it closed; drop the redundant private-account dependency section - Soften Soft Requirement #1 phrasing; drop the batching privacy claim and the shared-anonymity-set question; freeze -> admin authority on the release delay - Rewrite gas-token bootstrapping for clarity Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A proposal may commit to researching the gas-token leg and reporting findings rather than implementing it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extract the Ethereum consensus and state verification that RFP-021's mint path needs into its own RFP, so the primitive is built and audited once and shared with the other LEZ programs that need to read Ethereum state. The attestation establishes finality (sync-committee signatures over a light-client finality update), inclusion (Merkle-Patricia proof under the finalised header), and a predicate over the verified state, then emits a verified statement with no application action attached. Uniqueness stays with the consumer, keyed on a statement identifier the primitive supplies. RFP-021 now depends on RFP-022 for the inbound leg; the outbound leg (verifying a LEZ burn natively on Ethereum) stays in RFP-021. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RFP-021 carried gas-token bootstrapping as a soft requirement asking only for research. Deliver it properly as its own RFP: the LEZ program is the vault holding native gas token, the Ethereum contract is the minter, and the two directions mirror RFP-021 with the chains swapped. This closes a gap in the corpus. RFP-004, 008, 012 through 017 all fund gas by atomic deshield from the user's own shielded balance, precisely so no external funding source links the ephemeral account to an identity. That pattern presupposes the user already has funds on LEZ and says nothing about how they got there. RFP-023 is the trustless entry path for a user holding nothing. Supply is demand-driven: the ERC-20 is minted against proof of a lock in the LEZ vault and burned to release from it, so there is no float to seed and no incentive mechanism to design. The invariant that makes this sound is that the ERC-20 has no privileged minter and no pre-issued supply, which is exactly the Meter Passport failure mode already documented in the appendix. Privacy mirrors RFP-021 in full: each leg of each bridge has one public endpoint and it is the Ethereum one in every case. The one genuinely new problem is releasing native gas to a recipient who has none. Hard requirement that this must work for a zero-balance account with no required off-chain counterparty; mechanism left to the proposal. RFP-021 Soft Requirement #8 becomes a pointer to RFP-023. RFP-022 gains it as a third consumer of the attestation primitive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The release path previously said "must work for a zero-balance recipient" and left the mechanism open. Specify it: an off-chain paymaster is the third component of a deployment, alongside the LEZ vault and the EVM mint/burn contract with its dedicated ERC-20. Eligibility is a property of the proof, never of the requester. The paymaster sponsors a request iff it carries a valid attestation of a burn of its own deployment's ERC-20, above a configured minimum, not already sponsored. The nullifier that exists for double-spend protection doubles as the anti-abuse budget, so abusing the paymaster costs what acquiring and burning real ERC-20 costs. No account, allowlist, or registration. Reachable over Logos Delivery and over Tor, either alone sufficient. Tor is required rather than a nicety: Delivery's RLN spam protection may itself need LEZ gas, which the user by definition lacks, so a Delivery-only deployment could reintroduce the circularity this component exists to break. The paymaster must not observe requester IP addresses, by construction rather than by logging policy. This is the point where the user has no choice but to talk to somebody, so it is where the unlinkability of the whole design is most easily lost. Also require a defence against griefing. lez-proof-vault documents that fee reservation precedes execution and failed transactions are still charged, so a paymaster committing to pay before verifying can be drained by well-formed garbage. Mechanism is the proposal's choice; the cost bound must be measured. Narrows the network-anonymity out-of-scope bullet, which contradicted the new Tor and IP requirements. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Supportability already requires every hard requirement in Functionality, Usability, Reliability, Performance and Privacy Preservation to have at least one corresponding test. Restating that inside individual FURPS items as "Provide a test asserting..." was redundant. Where a clause named specific adversarial cases (tampered headers, mint-twice from one deposit, minting via an admin path, flooding the paymaster with ineligible requests), those cases are kept but phrased as conditions the requirement demands rather than as test instructions, so nothing is lost from the spec and the coverage obligation flows from Supportability as intended. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The requirement said the verifier "must be deployed as an immutable program ... in preference to an upgradeable contract governed by a mutable key". That is EVM proxy language mixed with Solana upgrade-authority language, and neither describes LEZ. LEZ has no upgradeability at all. A ProgramId is the RISC0 image ID computed from the bytecode, the deployed-program registry is append-only, redeploying identical bytecode is rejected, and a deployment transaction carries no authority or deployer identity. Changing one byte yields a different program, not a new version of the same one. So "deploy as immutable rather than upgradeable" was not a choice a proposal could make on the LEZ side, and the stolen-upgrade-key attack cannot arise there. What can arise is indirection. ChainedCall takes a ProgramId as an ordinary runtime field, and a program may hold one in its own account state, so an immutable bridge could still point at swappable verification logic. Whoever controls that pointer can repoint it at a verifier that accepts anything, which is the same fund-stealing capability relocated from the code to the pointer. The requirement now addresses the pointer on LEZ and the upgrade path on Ethereum, since only the Ethereum half has a genuine upgradeability question. RFP-022 additionally notes that its consumers inherit the same discipline, because they reference the module by image ID. Verified against logos-execution-zone: lee/state_machine/src/program/mod.rs (image ID derivation), validated_state_diff/mod.rs (append-only registry, ChainedCall dispatch), program_deployment_transaction/message.rs (bytecode only, unsigned). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The requirement is one sentence and had grown into twenty lines of platform background, plus two rationale paragraphs explaining LEZ program identity and ChainedCall indirection. None of it changed what an applicant builds. Requirements now read "The verification logic cannot be swapped", followed only by the two chain-specific bans that are the actual testable content. The rationale states plainly that mutable verification logic is unwanted and attributes the two risks correctly: whoever can change it can point the bridge at a verifier that accepts anything, which has no documented cross-chain bridge example, and an upgrade made in good faith can ship a catastrophic bug, which caused Nomad (~$190M) and nearly caused a second Ronin incident in 2024 ($12M, returned). Both figures and the no-stolen-upgrade-key finding are as sourced in the appendix. Also removes "which fixed verification logic forecloses by construction", which was ambiguous about what forecloses what. Net -45 lines. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The wrapped ERC-20 and Ether bridge becomes RFP-022 and the Ethereum state attestation primitive becomes RFP-021, so the shared primitive carries the lower number and its consumers follow it. Renames both files and swaps every ID, title, link and cross-reference across the three RFPs, the README table, the proposal dropdown and the bridges appendix. README and dropdown rows reordered to stay numeric. Also fixes references broken by the section restructure in the bridge RFP: - Privacy Preservation #8 -> #7 (an item was removed) - Supportability #8 (audit) -> Security #1, following the move to the new Security section - Supportability #9 (privacy properties document) was deleted, so the out-of-scope note now points at Privacy Preservation #6, which carries the surviving disclosure obligation - Soft Requirement #3 -> #2 (viewing keys, after deletions) - Soft Requirement #4's "as per F TODO" resolved to Security #8, the rule that verification logic cannot be swapped RFP-023's references into the bridge RFP updated for the same restructure: Bridge Security #8 -> Security #9, Bridge Security #7 -> Security #8, and the privacy-properties reference made self-contained since its target no longer exists. Minor: stray double space, a stray indent in a doc-packet item, and reflow of the newly added unwrapped lines. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FURPS items state the condition to be met; Supportability already requires a test for every hard requirement, so embedded "provide a test that..." instructions are redundant. Also drops a stranded "Provide" fragment left in RFP-023 item 3 by an earlier cleanup pass, and makes each outbound-unlinkability item readable on its own rather than deferring to the inbound item. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The RFP required trustless Ethereum verification but never said where the tracked sync-committee state lives, leaving applicants to guess between a shared on-chain light client and a bring-your-own-chain design that almost certainly cannot fit a single transaction. Specifies the expected shape: an operator advances shared consensus state, anyone may submit a proof-checked update, and consumers supply only inclusion proofs. Trust is a one-off deployment-time checkpoint, recoverable by fresh deployment rather than by a privileged party mutating an existing one. This removes the admin surface entirely, so the RFP-001 dependency goes with it. Adds an appendix surveying Telepathy, SP1 Helios and r0vm-helios, plus the Across fork that deliberately gates submission behind a role: the clearest evidence that permissionlessness is a design choice rather than something zk proofs confer automatically. Points applicants at r0vm-helios as a RISC Zero reuse candidate to assess, not to assume. Also corrects the consumption model, which described the primitive as a library and forbade depending on any account written by a third party. That contradicted the operator architecture. On testnet and mainnet this is a deployed program with an interface; what must stay in the consumer's transaction is inclusion and predicate evaluation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cost section now splits by execution path: BLS12-381 is needed only for headers, which are public and executed by the sequencer, while the open question is whether hash-based inclusion verification is viable in a private transaction proven on user hardware. Drops the secp256k1 ECDSA benchmark, which measured a different primitive on a different question. Replaces Ethereum-style "deployment" wording with the account model: the program is deployed once, and the checkpoint, chain binding, finality parameters, and tracked consensus state are per-instance configuration held in accounts. Adds reference consumer programs covering an ERC-20 transfer and a native ether transfer to a specific contract. Appendix records that an attestation spans two proof systems, the SSZ binding of the execution payload over SHA256 and the Merkle-Patricia path over keccak256, and that a log is proven through its receipt. Renumbers Supportability after dropping the per-item test and README items, and fixes the cross-references that pointed at the old numbering. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Extracted so the gas token bridge can be reviewed separately from RFP-021 and RFP-022. The cross-links from RFP-021 and RFP-022 stay, and resolve once the RFP-023 branch merges back into this one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Moves with the RFP to its own branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Inverts RFP-022: the LEZ program is the vault holding native gas token and the Ethereum contract is the minter, so a user who holds nothing on LEZ can acquire gas without an atomic deshield from a balance they do not have. Supply is demand-driven, with no privileged minter and no pre-issued ERC-20 supply. An off-chain paymaster sponsors release requests, gated on a valid attestation of a burn of its own deployment's ERC-20 rather than on any property of the requester, and reachable over Logos Delivery and over Tor so the request path does not itself require LEZ gas. Split out of the RFP-021 and RFP-022 branch so it can be reviewed on its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fryorcraken
force-pushed
the
rfp-023-gas-token-bridge
branch
from
August 19, 2026 04:36
9538c35 to
b5b1003
Compare
fryorcraken
force-pushed
the
rfp-021-wrapped-erc20
branch
from
August 27, 2026 03:56
348c9b0 to
86c1d1d
Compare
This was referenced Aug 28, 2026
Closed
fryorcraken
added a commit
that referenced
this pull request
Sep 8, 2026
RFP-021 is claimed by three older open pull requests, #158 and #169 for Ethereum state attestation and #57 for a cross-chain privacy DEX, so this one moves to the first free number past every current allocation. The table also gains placeholder rows for the five remaining deliverables in the suite, so a reader sees the shape of the whole set rather than one RFP that refers to five documents that do not appear anywhere. The two FFI layers are developer tooling; the JSON-RPC proxy, the two SDKs and the further transport modules are applications and integrations. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Extracted from #158 so the gas token bridge can be reviewed on its own.
Base branch is
rfp-021-wrapped-erc20, notmaster. RFP-023 depends onRFP-021 (the attestation primitive it consumes) and RFP-022 (the vault, mint,
registry, caps and privacy construction it inverts), and links to both plus
appendix/bridges-and-wrapped-tokens.md. Stacking on #158 keeps everycross-reference resolvable. Retarget to
masteronce #158 lands, or say theword and I will.
What it delivers
Every other LEZ application RFP assumes the user already holds gas: RFP-004,
008, and 012 through 017 all fund gas by atomic deshield from the user's own
shielded balance, precisely so no external funding source links the ephemeral
account to an identity. That pattern presupposes funds already on LEZ and says
nothing about how they got there. Nothing in the repo addressed the user who
holds nothing yet.
This inverts RFP-022: the LEZ program is the vault holding native gas token, the
Ethereum contract is the minter. Supply is demand-driven, so there is no float
to seed and no incentive mechanism to design; the ERC-20 has no privileged
minter and no pre-issued supply, which is exactly the Meter Passport failure
mode documented in the bridge appendix.
The one genuinely new problem is releasing gas to someone who has none. An
off-chain paymaster is the third deployment component: it sponsors a request iff
that request carries a valid attestation of a burn of its own deployment's
ERC-20, not already sponsored, so eligibility is a property of the proof and
never of the requester. Reachable over Logos Delivery and over Tor, either alone
sufficient, because Delivery's RLN spam protection may itself require LEZ gas
and a Delivery-only deployment would reintroduce the circularity. It must not
observe requester IP addresses by construction, since this is the one point
where the user has no choice but to talk to somebody.
Contents
RFPs/RFP-023-gas-token-bridge.mdproposal.ymldropdown entry, both moved here fromRFP-021, RFP-022: Ethereum state attestation and the wrapped ERC-20 bridge #158.
No appendix content moved:
appendix/bridges-and-wrapped-tokens.mdwas writtento support RFP-022 and is cited by all three RFPs, so it stays in #158. RFP-023
cites it for the Meter Passport native-gas-token mint, the one documented
cross-chain hack specifically about wrapping a gas token.
Review notes
fryorcraken/lez-proof-vaultis cited as prior art only. That repo implementsno paymaster and warns its own gasless pattern is not a valid example; what it
contributes is the reserve-before-verify griefing problem, which this RFP
requires a defence against.
requires coverage, so the adversarial cases appear as conditions the
requirement demands rather than as per-item test directions.
🤖 Generated with Claude Code