lambda-prize/prizes/LP-0003.md

dependencies

dependencies

LP-0003: Private Allowlist / Airdrop Distributor [OPEN]

Status: Open Logos Circle: N/A

Overview

Token airdrops and allowlist distributions today require recipients to expose their wallet address — and, by extension, their full on-chain history — at the moment of claim. The distributor must either publish the full eligibility list publicly or run a centralised gating service. Neither is acceptable for a privacy-first ecosystem.

This prize is for a private airdrop and allowlist primitive for LEZ: a contract where the distributor commits to a hidden set of eligible accounts, recipients can claim without revealing they were on the list, and no on-chain observer can link a claim to a specific eligible address.

Motivation

Airdrops are a primary token distribution mechanism for new protocols. Allowlists gate access to launches, NFT mints, and governance participation. In both cases the current pattern — publish a Merkle root, let users submit inclusion proofs — reveals eligibility and links pseudonymous identities to participation. For a community built around freedom and censorship-resistance, this creates real risks: eligible addresses can be targeted, excluded, or front-run.

Any commitment-based eligibility scheme involves trade-offs between distributor knowledge, claim-time privacy, and verifiability. Different approaches sit at different points in this space, and there is no single correct answer. The design space — commitment scheme, claim uniqueness mechanism, recipient UX, and integration with shielded token transfers — admits multiple valid approaches, which is exactly why a competitive prize is the right mechanism.

Logos' shielded account model offers a richer design surface than standard EVM environments. Submissions are expected to take advantage of this and explain how their design improves on the public Merkle airdrop baseline — and where the remaining trade-offs lie.

Success Criteria

Functionality

• A distributor can commit to an eligibility set on-chain without revealing individual addresses.
• An eligible recipient can claim their allocation without revealing which address in the set they hold.
• A recipient cannot claim more than once (double-claim prevention via nullifiers or equivalent).
• An on-chain observer cannot link a completed claim to any specific address in the eligibility set.
• The submission documents its full privacy model: what on-chain observers learn, what the distributor learns, at which points in the claim flow identity information is revealed or withheld, and where trade-offs or residual leakage remain. Claims of privacy must be precise — "unlinkable" must be defined relative to a stated threat model.
• A reference integration is delivered: a working demo of a private airdrop or allowlist gate on LEZ testnet.
• At least 2 distinct distributions are deployed on LEZ testnet, with a combined total of at least 20 unique claims completed across them; the distributions must be reproducible and evidence must be provided.
• 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 claimant.
• A failed or rejected claim does not mark the claimant as having claimed, allowing a retry.
• The verifier program returns deterministic, documented error codes for all invalid-proof and double-claim 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

• A LEZ program (Rust) implementing the commitment, claim, and distribution logic.
• ZK circuit(s) for eligibility and claim-uniqueness proofs, targeting the Risc0 proving stack.
• A client-side SDK or CLI for generating and submitting claims from shielded accounts.
• A reference integration on LEZ testnet: either a private token airdrop or a token-gated allowlist registration.
• Documentation covering: commitment scheme, claim-uniqueness mechanism, privacy model, trusted setup (if any), and integration guide.

Out of Scope

• Dynamic eligibility updates after commitment (the eligible set is fixed at distribution setup).
• Hiding the total number of eligible addresses or total allocation amount.
• Ongoing maintenance or security audits beyond initial delivery.

Prize Structure

• Total Prize: $600
• 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 with all circuit code, LEZ program code, and client-side tooling under MIT or Apache-2.0.
• Program deployed 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 a private claim from a shielded account. A silent screencast is not sufficient (see demo requirements).
• Reproducible deployment steps and evidence for at least 2 distinct distributions on LEZ testnet, with a combined total of at least 20 unique claims completed across them.
• Write-up covering: commitment scheme, claim-uniqueness mechanism, privacy model (what on-chain observers and the distributor learn at each stage, stated threat model, and any residual leakage or limitations), LEZ account model compatibility, security assumptions, known limitations, and integration instructions.
• Proof generation time and on-chain verification compute unit benchmarks.
• GitHub issues open for any problem encountered with Logos technology.
• FURPS self-assessment as part of the solution (see solution template).

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

• Logos Execution Zone repo
• Risc0 proving system
• Semaphore — nullifier and group membership design
• Merkle airdrop reference (public baseline)
• zk-kit — Merkle tree and nullifier primitives

Potential for Subsequent λ Prizes

Testnet 0.3/0.4 compatibility, mainnet deployment and adoption.