lambda-prize/prizes/LP-0002.md

dependencies

dependencies

LP-0002: Private M-of-N Multisig [OPEN]

Logos Circle: N/A

Overview

A proof-of-concept public M-of-N multisig exists for LEZ (lez-multisig), but it is architecturally incompatible with shielded (private) accounts. Member accounts must be fresh zero-nonce keypairs claimed by the multisig program — a constraint that private accounts, which are owned by the privacy protocol and increment nonce on every use, cannot satisfy.

This prize is for a private M-of-N multisig primitive for LEZ: one where members hold shielded accounts, proposals and approvals leave no public trace of who voted, and on-chain state reveals only that a threshold was met — not which members approved.

Motivation

Multisigs are critical infrastructure for DAOs, shared treasuries, and protocol governance. But a multisig that exposes its member list and approval history on-chain is a surveillance surface: it reveals voting patterns, enables social pressure, and links member identities to governance decisions. For a privacy-first ecosystem like Logos, a public multisig is a second-class primitive.

The lez-multisig PoC explicitly notes in its design documents that private multisig support "would require shielded voting and ZK threshold proofs" — a fundamentally different architecture. This prize builds that architecture.

A competitive prize is the right mechanism because the design space is large: choice of threshold proof scheme, how to handle the LEZ nonce constraint, nullifier design to prevent double-voting, and the trade-off between proof size and verifier gas cost all admit multiple valid approaches.

Success Criteria

Functionality

• Any M-of-N member holding a shielded LEZ account can submit an approval without revealing their identity to on-chain observers or other members.
• The on-chain verifier confirms a threshold of M approvals was reached without recording which members approved.
• A member cannot approve the same proposal twice (double-vote prevention via nullifiers or equivalent).
• A completed execution is unlinkable to any individual member's shielded account.
• Proof generation runs client-side on a standard laptop.
• A reference integration is delivered: a working demo of a threshold-gated action (e.g., treasury transfer or parameter change) on LEZ testnet using shielded member accounts.
• At least 1 multisig instance is created on LEZ testnet, with at least one proposal submitted, approved by threshold, and executed; the deployment 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 member.
• A partial set of approvals (fewer than M) is preserved and resumable across client restarts.
• The verifier program returns deterministic, documented error codes for all invalid-proof and double-vote 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 threshold membership proof and double-vote prevention, targeting the Risc0 proving stack.
• A LEZ verifier program (Rust) that accepts threshold proofs and gates execution.
• A client-side SDK or CLI for proof generation and proposal submission by shielded account holders.
• A reference integration on LEZ testnet demonstrating M-of-N threshold approval of at least one on-chain action.
• Documentation covering: cryptographic approach, nullifier/anti-replay scheme, trusted setup (if any), LEZ account model compatibility, security assumptions, and integration guide.

Out of Scope

• Public (non-shielded) multisig — the lez-multisig PoC covers that use case.
• Hiding the proposal content (only member identity and vote are private; the proposed action may be public).
• A polished consumer UI — a working demo is sufficient.
• Ongoing maintenance or security audits beyond initial delivery.

Prize Structure

• Total Prize: $1,200
• Effort: Large

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.
• Verifier 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 M-of-N approval and execution using shielded member accounts. A silent screencast is not sufficient (see demo requirements).
• Reproducible deployment steps and evidence for at least 1 multisig instance on LEZ testnet, with at least one proposal submitted, approved by threshold, and executed.
• Write-up covering: threshold proof scheme, nullifier design, LEZ account model compatibility (specifically how the nonce and program_owner constraints are handled), security assumptions, known limitations, and integration instructions.
• Proof generation time and on-chain verification gas cost benchmarks.

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

• lez-multisig — public multisig PoC; architecture notes describe why private accounts are incompatible
• Logos Execution Zone repo
• Risc0 proving system
• Semaphore — ZK anonymous signalling and nullifier design
• MACI — Minimum Anti-Collusion Infrastructure
• Threshold signature schemes (FROST)

Potential for Subsequent λ Prizes

This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment.