logos-co/lambda-prize
1
0
Fork 0
mirror of https://github.com/logos-co/lambda-prize.git synced 2026-08-30 19:11:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
github-lambda-prize-issue-template
lambda-prize/prizes/LP-0001.md
T
mart1n 61986e4bd3 Add evaluation policies and rename mini-app to Logos Basecamp app 
Introduce programme-wide evaluation policies to raise the bar for
submissions:

- Max 3 submissions per prize per builder, one submission/review per week
- Pass/fail feedback only; detailed guidance via Discord
- Demos must be narrated video walkthroughs covering architecture,
  decisions, and full end-to-end flow — silent screencasts rejected

Policies are defined in README (Evaluation Policies section) and
replicated in every non-closed LP's Evaluation Process for
self-contained readability. Demo specifics are tailored per prize
in each LP's Submission Requirements.

Also renames "Logos mini-app" → "Logos Basecamp app" throughout all
prizes and the template.

Made-with: Cursor
2026-04-10 11:22:16 +02:00

6.4 KiB
Raw Permalink Blame History

LP-0001: Private NFT Ownership Proof [DRAFT]

Status: draft - pending NFT Program readiness Logos Circle: N/A

Overview

Token-gating is everywhere — allowlists, governance votes, exclusive channels — but today it requires revealing exactly which token you hold. This prize is for a ZK-based membership proof system that lets a user prove they own some NFT from a collection without disclosing which one.

The result is a reusable primitive: a Logos Execution Zone (LEZ) contract and a client-side proving workflow that any dApp can integrate to offer privacy-preserving token-gated access.

Motivation

Current token-gating solutions force users to sign messages that expose their wallet address and the specific token they hold. This leaks on-chain identity, enables correlation attacks, and undermines the pseudonymity that many users rely on. A ZK membership proof — where the proof attests "I own a token in this collection" without revealing which one — is a natural fit for Logos' shielded execution model and closes this gap cleanly.

A competitive prize is the right mechanism here because the problem is well-specified but the implementation space is large: circuit design, nullifier schemes, Merkle tree construction, and gas cost trade-offs all admit multiple valid approaches. Competition surfaces the best solution.

Success Criteria

Functionality

  • A user holding any NFT in a given collection can generate a client-side ZK proof of ownership on a standard laptop.
  • The proof can be verified on LEZ without revealing the token ID or the holder's wallet address to the verifier.
  • The system is resistant to proof reuse across contexts — a nullifier or domain-separation mechanism prevents the same proof from being replayed in a different gating context.
  • A reference integration is delivered: a working demo of at least one token-gated action (e.g., allowlist registration or an on-chain vote) using the proof system.
  • At least 5 independent NFT collections are deployed on LEZ testnet with the proof system integrated, each by a distinct team or community outside the submitting team.
  • Full documentation and a clean public repository are delivered.

Usability

  • Provide a module/SDK that can be used to build Logos modules for interacting with the program.
  • Provide a Logos Basecamp app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp).
  • Provide an IDL for the LEZ program, using the SPEL framework.

Reliability

  • The system handles proof generation failures gracefully and surfaces a clear error to the user.
  • The verifier program returns deterministic, documented error codes for all invalid-proof scenarios.

Performance

  • Document the compute unit (CU) cost of each on-chain operation on LEZ devnet/testnet. Note: LEZ's per-transaction compute budget may change during testnet.

Supportability

  • The program is deployed and tested on LEZ devnet/testnet.
  • End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI.
  • CI must be green on the default branch.
  • A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and Basecamp app.
  • A reproducible end-to-end demo script is provided and works against a real local sequencer with RISC0_DEV_MODE=0.
  • A recorded video demo of the end-to-end flow is included in the submission; the recording must show terminal output (including proof generation) to confirm RISC0_DEV_MODE=0 was active.

Scope

In Scope

  • ZK circuit(s) implementing the membership proof over an NFT collection's ownership set, targeting the Risc0 proving stack.
  • A LEZ verifier program (Rust) that accepts and verifies proofs on-chain.
  • A client-side SDK or CLI tool for proof generation.
  • A reference integration demonstrating at least one token-gating use case (allowlist, voting, or access control) on LEZ testnet.
  • Documentation covering the cryptographic approach, any trusted setup requirements, and an integration guide.

Out of Scope

  • Multi-chain or cross-chain ownership proofs.
  • A polished consumer-facing UI — a working demo is sufficient.
  • Ongoing maintenance or security audits beyond initial delivery.

Prize Structure

  • Total Prize: $TBD
  • Effort: Medium

Eligibility

Open to any individual or team. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT or Apache-2.0.

Submission Requirements

  • Public repository containing all circuit code, LEZ program code, and client-side tooling, licensed under MIT or Apache-2.0.
  • Deployment of the verifier program on LEZ testnet, with a verified program ID.
  • End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates proof generation and on-chain verification for at least one token-gating use case. A silent screencast is not sufficient (see demo requirements).
  • A write-up covering: cryptographic approach, proving system used, Merkle tree construction, nullifier/domain-separation scheme, security assumptions, known limitations, and integration instructions.
  • Gas cost benchmarks for on-chain verification.
  • GitHub issues open for any problem encountered with Logos technology.

Evaluation Process

Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies all criteria wins.

Evaluators will independently clone the repository and run the demo script from a clean environment; the script must succeed without modification. Evaluators may also ask technical follow-up questions to verify authorship and understanding of the implementation.

The following policies apply to all prizes (see evaluation policies):

  • Submissions: each builder (or team) is allowed a maximum of 3 submissions per prize, with at most one submission/review per week.
  • Feedback: initial evaluation feedback is limited to a pass/fail indication against the success criteria.

Resources

Potential for Subsequent λPrizes

TBD

Reference in New Issue View Git Blame Copy Permalink