New RFP: RFP-021, Trustless Ethereum State Attestation for LEZ (Tier M)

Tech
1

The opportunity

A LEZ program establishes its correctness given its inputs. Whether an input is a true statement about Ethereum is outside what that execution establishes: a program that acts on “this deposit happened on Ethereum” has to take that claim on trust.

RFP-021 invites proposals for a reusable LEZ primitive that closes that gap with no trusted intermediary. It verifies Ethereum consensus and finality, verifies that a referenced piece of state is included under a finalised Ethereum header, evaluates a predicate over that state, and emits a verified statement any LEZ program can consume.

The primitive is application-free by design: minting, escrow release, settlement and every other action belong to the consuming program. Building the verification once means the most security-critical part of any cross-chain design gets one audited verification path, one test suite, and one set of documented trust assumptions, shared by every program that needs to read Ethereum.

What you’d build

  • An Ethereum light client running inside a LEZ program: from a trusted checkpoint, it verifies light-client updates and sync-committee handoffs, including the BLS12-381 aggregate signature, without running a full node.
  • Finality and inclusion verification for accounts, contract storage slots, and event logs under a finalised header, with a predicate interface (at least equality and inequality) that consuming programs use without modifying the module.
  • Verified statements bound to their chain identity, carrying a deterministic identifier a consumer can key a nullifier on.
  • Permissionless consensus-state updates: any party can advance an instance, with no allowlist or registration, and no off-chain participant in a trust role.
  • No new correlation signal: verifying and consuming an attestation must not reveal the consuming LEZ account or transaction.
  • Cost measurement as a primary output: cycle count, gas cost, proof time, and proof size for advancing the tracked state and for each type of statement.
  • A Logos core module, an update-submitting component as a Logos module with a headless CLI/daemon, an IDL using SPEL, and documentation in repo.

Is this a fit for your studio or team?

This RFP suits teams 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 review 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

Engagement details

  • Tier: M
  • Estimated development duration: 8 to 12 weeks
  • Output: a testnet implementation, tested on LEZ testnet 0.4 and attesting to state on a public Ethereum testnet
  • Audit: an independent third-party security audit of the consensus and inclusion verification logic is required before any production deployment; it is not included in the duration estimate and is typically procured and scheduled separately
  • License: MIT and Apache 2.0 dual license
  • Submission deadline: 11th of November 2026 (UTC)

How to apply

Questions about scope, the Logos Ethereum core module, or LEZ program constraints are welcome right here in this thread. Ask early, and keep coming back while you write your proposal.

Discord discussion: Discord

Participation is subject to the Terms & Conditions.

1 Like