lambda-prize/prizes/LP-0002.md

# 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](https://github.com/jimmy-claw/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 5 distinct multisig instances are created on LEZ testnet by parties outside the submitting team, with at least one proposal submitted, approved by threshold, and executed in each.
- [ ] 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 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](../README.md#evaluation-policies)).
- 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](../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-multisig](https://github.com/jimmy-claw/lez-multisig) — public multisig PoC; architecture notes describe why private accounts are incompatible
- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/)
- [Risc0 proving system](https://dev.risczero.com/)
- [Semaphore — ZK anonymous signalling and nullifier design](https://semaphore.pse.dev/)
- [MACI — Minimum Anti-Collusion Infrastructure](https://privacy-scaling-explorations.github.io/maci/)
- [Threshold signature schemes (FROST)](https://eprint.iacr.org/2020/852)

## 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.