mirror of
https://github.com/logos-co/lambda-prize.git
synced 2026-08-30 19:11:06 +00:00
mart1n
61986e4bd3
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
104 lines
6.4 KiB
Markdown
104 lines
6.4 KiB
Markdown
# 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](https://github.com/logos-co/spel).
|
|
|
|
### 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](../README.md#evaluation-policies)).
|
|
- 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](../README.md#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
|
|
|
|
- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone)
|
|
|
|
## Potential for Subsequent λPrizes
|
|
|
|
TBD |