From c87ac7dd7cb654d7bf7a97698fe4c238302a0b64 Mon Sep 17 00:00:00 2001 From: Sasha Date: Wed, 2 Sep 2026 06:16:57 +0000 Subject: [PATCH 1/3] =?UTF-8?q?LP-0025:=20Private=20DAO=20=E2=80=94=20prop?= =?UTF-8?q?osal=20lifecycle,=20deliberation,=20and=20voting-weight=20deleg?= =?UTF-8?q?ation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Drafts the composition layer for private DAO governance: lifecycle, per-proposal deliberation, private voting with member weight, and delegation. Execution, voting and deliberation sit behind adapters so the prize is buildable ahead of RFP-005 and a private-voting spec. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 1 + prizes/LP-0025.md | 279 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 280 insertions(+) create mode 100644 prizes/LP-0025.md diff --git a/README.md b/README.md index d4ad00d1..debeef7f 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md)) | +| [LP-0025](prizes/LP-0025.md) | Private DAO: proposal lifecycle, deliberation, and delegation | Large | Draft | ### Proposing a New Prize diff --git a/prizes/LP-0025.md b/prizes/LP-0025.md new file mode 100644 index 00000000..22e0aea0 --- /dev/null +++ b/prizes/LP-0025.md @@ -0,0 +1,279 @@ + + +--- +dependencies: + - id: LP-0003 + reason: Private allowlist / airdrop distributor — the membership bootstrap. A DAO's anonymity set is its membership set; LP-0003 is the primitive that admits members to it without publishing who they are. + - id: RFP-005 + reason: Multisig and Coordination — the execution layer. A passed proposal has to execute against a treasury or an admin authority, and RFP-005 is the M-of-N program (plus per-instance coordination room) this app is expected to drive. +--- + +# LP-0025: Private DAO — proposal lifecycle, deliberation, and voting-weight delegation [DRAFT] + +**`Status: Draft`** +**`Logos Circle: N/A`** + +## Overview + +A DAO is not a voting contract. It is a loop: someone raises a proposal, members argue about it, members vote on it, and — if it passes — something executes against a treasury or an admin authority. Logos has, or is building, a component for each of those steps. What does not exist is the thing that makes them one organisation. + +This prize funds a **Private DAO app for Logos Basecamp**: the proposal lifecycle that carries a decision from draft to execution, the deliberation surface bound to each proposal, private voting with member-held weight, and voting-weight delegation — with a privacy boundary that holds *across* those steps rather than inside each one. + +The hard part is not any single layer. It is the seams. A ballot cast privately still leaks if the deliberation thread beside it is attributable, if the weight it carries is unique, or if the execution that follows names the members who authorised it. And delegation — the mechanism every large DAO relies on to get turnout at all — is in direct structural tension with ballot privacy. A submission has to take a position on that tension and defend it, not paper over it. + +## Motivation + +### Public governance is the norm, and it is measurably distorted + +Every major governance venue records a permanent, public link between a voting address and a choice. Snapshot votes are signed messages; on-chain governors record transactions. A peer-reviewed dataset covering October 2020 – November 2023 records roughly 19,200 spaces, 127,000 proposals, and 51 million votes on Snapshot alone — all of it attributable, all of it permanent. + +The measured consequences of that design: + +- **Turnout is low and power is concentrated.** Against all token holders, turnout runs 1–2%; a cross-DAO average of 6.3% has been reported. One review found the single largest actor holding 35% of voting power and the top three holding 63% between them. +- **Voting is biased by what voters can see.** A 2026 analysis of the Snapshot dataset measures an author-selected-choice effect of +58.8 pp, an approval-oriented-choice effect of +27.1 pp, and a first-listed-choice effect of +7.7 pp on voting-power share. The authors' conclusion is that ordering, author signals, and vote visibility are institutional design choices, not neutral implementation details. +- **Public votes are sellable.** Vote markets — Votium, Hidden Hand, Paladin — work precisely because payment can be made conditional on a vote the buyer independently verifies. The foundational analysis ("On-Chain Vote Buying and the Rise of Dark DAOs", IC3 2018) names the two properties on-chain voting breaks: **receipt-freeness** (a voter cannot prove how they voted) and **coercion resistance** (a voter can credibly lie about it). A 2023 follow-up, published at USENIX Security 2025, demonstrates a working Dark DAO prototype and finds that systemic bribery risk *increases* with decentralisation. + +### Delegation is where privacy and accountability collide + +Delegation is not a side feature. It is how large DAOs reach quorum at all — and it consolidates rather than disperses influence. Across ENS, Uniswap, Compound and Aave, voting-power Gini sits at 0.94–0.99; ENS's Nakamoto coefficient is **1**, meaning a single delegate holds a majority of participating power. + +Delegated governance also *institutionalises* public voting. Uniswap's DAO Principles (Proposal 78, January 2025) require delegates to publish vote rationales and disclose conflicts; the Delegate Reward Initiative attaches payment to a seven-day rationale deadline; Optimism and Arbitrum publish comparable expectations. A delegate who cannot be seen voting cannot be held accountable — and a member who can be seen voting can be coerced. + +This is a genuine design fork, and the two shipped answers go in opposite directions. Penumbra keeps validator (delegate) votes transparent and attributable while hiding delegator choices — but leaks the voting power used and which validator was delegated to, which shrinks the anonymity set whenever a validator has few delegators. The Nouns Private Voting Research Sprint's Poseidon team made the opposite trade, keeping voter addresses public *specifically* to preserve delegation and multisig support. + +**No production system achieves receipt-freeness or coercion resistance in the formal sense.** Penumbra's voter can prove how they voted. MACI's receipt-freeness holds only against a coordinator who does not collude with the briber. This prize does not require solving that open problem — it requires the submission to state precisely where it lands on it. + +### Why a prize, and why now + +The individual layers are being addressed: execution by RFP-005, membership by LP-0003, deliberation by the Forum Sample App line and by LP-0016's delivered moderation SDK. Composition is the gap, and it is the part with no obvious right answer — the design space (where the privacy boundary sits, how delegation is reconciled with accountability, how quorum is proven over hidden weights, how spam is bounded under anonymity) admits several defensible positions. That is what a competitive prize is for. + +It is also the gap that makes the rest legible. A private multisig with no organisation around it is a shared wallet. A DAO is what turns the Logos stack into something a group can actually run. + +## Success Criteria + +### Functionality + +**Proposal lifecycle** + +- [ ] A member can create a proposal carrying, at minimum: a title, a body, the executable action it authorises (target program and decoded instruction), a voting window, and the quorum and passing thresholds in force. Proposal states are explicit and enforced by the program, not by client convention: `draft → deliberation → voting → passed | failed → (time lock) → executed | expired`, plus `cancelled`. +- [ ] **Voting weight is snapshotted** at the transition into `voting`. Weight acquired, transferred, or delegated after the snapshot does not count toward that proposal. +- [ ] **Anonymous proposal spam is bounded.** Under unlinkable membership, an eligibility proof alone permits unlimited proposals. Submissions must bound proposal creation — a per-epoch rate-limiting nullifier, a refundable deposit, a proposal-weight threshold, or an equivalent — without deanonymising the proposer. The chosen mechanism must be enforced on-chain or by the verifying program, not by the UI. +- [ ] A proposal that fails quorum, fails its threshold, or expires unexecuted terminates in a state the program will not execute from. + +**Voting** + +- [ ] A member casts a ballot carrying their snapshotted weight without revealing, to any observer including the tallier, which member they are or how they voted. +- [ ] **Double-voting is prevented cryptographically** — nullifiers or equivalent — including across the direct/delegated boundary (below). +- [ ] **Quorum and thresholds are proven over hidden weights.** The result publishes the aggregate; the tally proves that participating weight met quorum and that the passing threshold was reached, without publishing per-ballot weight. Where the design leaks weight (a ballot revealing its own magnitude, for example), that leak must be stated and quantified, not assumed harmless. +- [ ] **Governance attestation.** A DAO can produce a verifiable statement about its own governance — at minimum the number of distinct members who voted on a proposal, the number of distinct delegators and delegates in force at snapshot, and that no weight was double-counted — **without revealing which members those were**. This is what lets a private DAO demonstrate legitimacy to an outsider (a grant funder, a counterparty, an evaluator) instead of asking to be trusted, and it is the mechanism the Adoption section below is evidenced against. +- [ ] The submission states which privacy boundary it implements — **delayed reveal** (ballots published after voting closes) or **never-decrypt** (only the aggregate ever opens) — and why. Only the latter defends against retaliation, coercion, or post-hoc vote buying; a delayed-reveal design must argue explicitly why that is acceptable for its target user. + +**Delegation** + +- [ ] A member can delegate their voting weight to another member, change that delegation, and revoke it. Delegation takes effect no later than the next proposal snapshot. +- [ ] **Direct votes and delegated weight cannot double-count.** If a delegating member votes directly on a proposal, exactly one of the two ballots counts, and which one is defined by the protocol and enforced by the verifier — not resolved by the client or by tallier discretion. +- [ ] **The delegation privacy position is explicit and enforced.** The submission must state, and implement, who can see what: whether a delegate's votes are attributable (accountability, Uniswap/Optimism/Arbitrum-style) or private (coercion resistance), and whether the delegation edge itself — *who delegated to whom* — is public, private, or private-with-leakage. Silence on any of the three is a failing answer; a defended trade-off is a passing one. +- [ ] **Delegation does not silently collapse the anonymity set.** The submission must document how small delegate cohorts affect member privacy (a delegate with one delegator identifies that delegator's weight) and what the implementation does about it. + +**Deliberation** + +- [ ] Each proposal has a deliberation surface — a thread, room, or channel — bound to the proposal such that any member can verify the discussion belongs to that proposal and was authored by members, without deanonymising the authors. +- [ ] Deliberation runs on the Logos stack (Logos Delivery and/or the Logos chat module). No centralised server or hosted backend. +- [ ] The deliberation record is durable enough that a member joining after a proposal closed can read the argument that produced the outcome. +- [ ] Moderation, if the instance enables it, must not be a deanonymisation channel. Submissions reusing LP-0016's threshold-moderation SDK inherit its documented retroactive-linkability-on-slash property and must state how that interacts with voting privacy. + +**Membership** + +- [ ] A DAO is created with a membership set and its governance parameters (quorum, thresholds, voting window, delegation policy). Members are admitted without the membership roll being published — the intended path is LP-0003's private allowlist, and any substitute must offer an equivalent privacy property and say so. +- [ ] Membership changes (admission, exit, weight change) go through the DAO's own governance path, so the member set cannot be altered outside the process it governs. + +**Composition boundary** + +- [ ] **Execution is behind a documented adapter.** A passed proposal executes through an execution backend the DAO app does not itself implement. The app must define that interface and ship at least one working backend. If the RFP-005 multisig is available at submission time, it must be the primary backend; otherwise the submission ships a minimal reference backend and demonstrates the adapter by swapping it. Hard-coupling the lifecycle to one execution implementation does not satisfy this criterion. +- [ ] The same applies to voting and deliberation: each is reached through an interface with at least one working implementation, so a component delivered later (a private-voting primitive, forum v0.2+) can replace the submission's own without rewriting the lifecycle. + +**Cross-layer privacy accounting** + +- [ ] A **privacy accounting document** covering the whole loop, not component-by-component: for each step (join → delegate → propose → deliberate → vote → tally → execute), what a passive network observer, a fellow member, a delegate, a tallier or coordinator, and an on-chain observer each learn — and what they learn from *correlating* steps. Timing correlation between a forum post and a ballot, weight uniqueness, delegate cohort size, and the identity of whoever submits the executing transaction must each be addressed explicitly. Per-component privacy claims that do not compose are the failure mode this criterion exists to catch. +- [ ] A stated threat model naming which adversaries the design defends against and which it does not, including an explicit position on receipt-freeness and coercion resistance. + +### Usability + +- [ ] A Logos Basecamp app covering the full member journey — join, delegate, propose, deliberate, vote, watch a result execute — usable without CLI interaction or manual transaction crafting. +- [ ] An SDK/module with a documented API, so another Logos app can drive the lifecycle without embedding this app's UI. +- [ ] Before a member votes, the app displays the exact action the proposal authorises — target program, decoded instruction, amounts — rather than a UI-rendered summary. +- [ ] An IDL for every LEZ program delivered, using the [SPEL framework](https://github.com/logos-co/spel). +- [ ] The privacy posture is legible in the UI: at each action a member can see what that action publishes. A member should not have to read the threat model to learn that delegating is visible. + +### Reliability + +- [ ] Proof-generation failures surface a clear error and permit retry without consuming the member's nullifier or forfeiting their ballot. +- [ ] Transient Logos stack failures (delivery or storage unavailability) queue and retry rather than silently dropping a ballot, a post, or a delegation change. +- [ ] A proposal cannot execute twice, cannot execute after expiry, and cannot execute on an action other than the one voted on. +- [ ] Governance-parameter changes cannot retroactively alter an in-flight proposal: the parameters in force at snapshot are the ones the tally is evaluated against. +- [ ] Deterministic, documented error codes for every invalid-ballot, double-vote, quorum-failure, and expiry path. + +### Performance + +- [ ] Ballot proof generation completes in **under 10 seconds** on a standard laptop, matching the bar set by LP-0016. +- [ ] Tally verification cost is documented **as a function of member count and of participating-weight distribution**, with the largest DAO size that remains viable within LEZ block limits reported. If the viable ceiling is small, that finding is a reportable result rather than something to be silently shipped around. +- [ ] Compute-unit / cycle counts documented for every on-chain operation (DAO creation, membership change, delegation, ballot submission if on-chain, tally, execution), benchmarked with **real proving** (`RISC0_DEV_MODE=0`). Development-mode figures are not accepted. + +### Supportability + +- [ ] Deployed and tested against the current Logos testnet; the targeted version is stated. +- [ ] Builds and runs end-to-end on **macOS (Apple Silicon)** and **Linux (x86_64)**. +- [ ] The Logos Core module is built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) and published to a module catalog ([`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base) fork), with the `logos-repo.json` URL supplied so evaluators can install it through the package-manager UI / `lgpd`. +- [ ] End-to-end integration tests covering the full lifecycle run against a LEZ sequencer in standalone mode and are included in CI; CI green on the default branch. +- [ ] Every functionality and reliability requirement has at least one corresponding test. At minimum: a proposal cannot execute below quorum; a delegated member voting directly is counted exactly once; a post-snapshot delegation does not affect the in-flight proposal; an expired proposal cannot execute. +- [ ] A reproducible end-to-end demo script that works against a real local sequencer with `RISC0_DEV_MODE=0`. +- [ ] README covering deployment, program addresses, and the full operator and member journeys. +- [ ] **No mandatory centralised external services.** Beyond the user's configured sequencer, LEZ node, and Logos protocols, neither the app nor its tooling may depend on a third-party web service. Any analytics is strictly opt-in. + +### Adoption + +> These metrics measure traction attributable to a given submission for this prize. +> +> **All of the following are required in addition to the FURPS criteria above**, except where marked *(Discretionary)*. We publish the dimensions we look at, but hitting a raw number is not by itself sufficient (see [Terms & Conditions](../TERMS.md) for the evaluation policy that applies to all prizes). Volume that is clearly manufactured does not count, regardless of the headline number. + +**On-chain activity (operator-side)** + +- [ ] 10 DAOs created on the official Logos zone carrying this submission's identifier, from at least 10 distinct operator accounts independent of each other and of the submitting team. Accounts with no prior unrelated testnet activity carry little weight; accounts created in a burst around the submission date do not count. +- [ ] 30 proposals reach a terminal state — deliberated, voted, and either executed or terminally failed at quorum or threshold. Proposals created and abandoned do not count. **At least 10 must have executed an action** against a treasury or an admin authority. +- [ ] The 30 proposals are spread over at least 2 months, with at least 10 in each of those months. A single burst does not qualify, however large. + +**Attested participation (member-side)** + +- [ ] Across those proposals, at least **100 distinct members** cast a ballot, and at least **50 delegations** are in force from at least **30 distinct delegators** across at least **6 distinct delegates**, with no single delegate holding more than 40% of delegated weight in any DAO counted here. Supplied as governance attestations — proofs of the counts, not lists of the accounts. Attestations must be independently verifiable by an evaluator against on-chain state, and a DAO that can only supply these numbers by disclosing its membership roll does not satisfy this criterion. + +**Contested outcomes** + +- [ ] In at least 8 of the 30 proposals, the losing side carried 25% or more of participating weight. Governance that only ever ratifies is not evidence that anyone deliberated, and contested proposals are the only ones under which the privacy guarantees are load-bearing — they are where a member has something to lose by being seen voting. + +**Logos Circle adoption** + +- [ ] At least 2 Logos Circles use the deliverable to govern their own activity. For each: a named steward, a written statement of what it is used for and since when, and a re-confirmation at the T+3-month retention check. A Circle that has stopped using it does not count. + +**Continued use after the award** + +- [ ] At least 10 reproducible issues were opened by people outside the submitting team and resolved, with a linked fix. Median first response under 7 days over the observation window. + +**Discretionary** + +- Testimonials from people who actually participated in a DAO built on this app, each describing a specific decision they voted on. Evaluators will contact a random sample and ask what they did with it; unanswered or generic replies count against the submission. Account tenure and posting history are inspected. *Members are welcome to vouch publicly; nothing in this prize asks them to, and a submission that pressures members into attributable public participation will be marked down for it.* +- Tutorials, walkthroughs, or conference talks by people outside the submitting team that demonstrate working use — not a restatement of the project's own documentation. A written account of how a group actually reached a decision using the app is worth more here than a feature tour. +- Used in a Logos-run workshop, Circle meetup, or hackathon by attendees who are not the submitting team, with a Logos-side observer. +- An independent write-up by a party unaffiliated with the submitting team that attempts the correlation attacks the privacy accounting document claims are infeasible, and publishes what it found. A confirming result and a refuting result both count; a refuting result the submission then fixes is the better outcome. + +## Design Decisions Left to the Submitter + +The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it: the reasoning is part of what is evaluated. + +- **Where the privacy boundary sits.** Delayed reveal or never-decrypt; and if never-decrypt, what opens the aggregate — a threshold committee, a coordinator, or base-layer consensus. Almost every production-grade shielded voting system rests on a threshold committee (Shutter's keypers, Vocdoni's sequencers, MACI's coordinator); the designs that avoid one remain unshipped research. Adding a committee is defensible. Adding one without saying so is not. +- **The delegation/accountability split.** Penumbra makes delegate votes transparent and delegator choices private. Poseidon's Nouns-sprint design kept voters public precisely to preserve delegation. Both are coherent; pick one, or a third, and defend it against the coercion argument on one side and the accountability argument on the other. +- **Whether the delegation graph is private.** Hiding *who delegated to whom* protects members but complicates weight accounting and makes delegate cohort size unauditable — which is itself a privacy risk for members in small cohorts. +- **How anonymous proposal rights are rate-limited.** Deposits, weight thresholds, and rate-limiting nullifiers each cost something different in privacy, capital, or liveness. +- **What binds deliberation to a proposal.** A cryptographic binding proves the thread is the proposal's, but a thread that is verifiably a specific proposal's discussion is also a correlation surface against the ballots cast on it. +- **Whether governance weight is token-based, membership-based, or reputation-based**, and what that implies for LP-0003 as the bootstrap. One-member-one-vote and token-weighted governance have materially different privacy properties: uniform weight is a much larger anonymity set than a distribution with distinguishable magnitudes. + +## Scope + +### In Scope + +- The DAO Basecamp app and its SDK/module: proposal lifecycle, deliberation binding, voting, delegation, membership management. +- The LEZ program(s) backing lifecycle state, weight snapshotting, delegation accounting, nullifiers, and tally verification. +- Execution, voting, and deliberation adapters, each with at least one working implementation. +- The cross-layer privacy accounting document and threat model. +- Integration tests, CI, catalog publication, and the end-to-end demo. + +### Out of Scope + +- **Building the private multisig itself.** Execution is reached through the adapter; RFP-005 owns the multisig. +- **Building a general-purpose forum.** Deliberation here is proposal-scoped. The general forum is the Forum Sample App line and its own prize ([logos-co/ecosystem#193](https://github.com/logos-co/ecosystem/issues/193)). +- **Building the membership primitive.** LP-0003 owns private allowlists. +- Off-chain governance tooling: delegate directories, proposal analytics, vote-explorer dashboards. +- Cross-DAO identity, cross-DAO reputation, or interoperability with existing DAO frameworks (Aragon, Safe, Snapshot). +- Legal wrappers, entity formation, or anything implying a DAO is or is not a legal person. +- Solving receipt-freeness or coercion resistance in the formal sense. State where the design lands; do not be required to close an open research problem. + +## Prize Structure + +- **Total Prize:** $3,000 +- **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. + +DAOs, proposals, delegations and testimonials counted under **Adoption** must come from participants independent of the submitting team. + +## Submission Requirements + +- Public repository (dual licensed MIT **and** Apache-2.0) containing the Basecamp app, the SDK/module, the LEZ program(s) and their IDLs, the adapters and their reference backends, and the tests. +- The **privacy accounting document** and threat model, as the substantive design artefact of the submission. +- Deployed program IDs on the targeted testnet, and the module catalog `logos-repo.json` URL. +- Performance evidence: ballot proof timings, tally cost as a function of member count, and compute-unit figures produced with real proving. +- Evidence for each adoption criterion: the DAOs and their membership counts, the completed proposals with per-month counts, the delegation records and the proposals whose outcome turned on delegated weight, the independently-operated DAO and what it governed, and the Discord and Twitter/X testimonials. +- A narrated video walkthrough (see [demo requirements](../README.md#evaluation-policies)) demonstrating: DAO creation and member admission, a proposal moving through deliberation to a passing vote and executing, a delegated member's weight counted through their delegate, that same member voting directly and being counted exactly once, and a proposal failing quorum and being unable to execute. +- FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). +- GitHub issues filed for any problems encountered with Logos technology. + +## Evaluation Process + +By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets **all** criteria wins. + +Because the adoption criteria require sustained activity over at least two months, a submission cannot qualify until that window has elapsed. Builders are encouraged to ship early and accrue real governance activity while continuing to develop, rather than treating the build and the adoption push as sequential. + +Evaluators will independently clone the repository and run the demo script from a clean environment; the script must succeed without modification. Evaluators will additionally join a running DAO as an ordinary member and attempt the correlation attacks the privacy accounting document claims are infeasible — a document whose claims do not survive that is a failing submission regardless of the code. Evaluators may ask technical follow-up questions to verify authorship and understanding. + +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 + +**Logos** + +- [LP-0003](./LP-0003.md) — Private Allowlist / Airdrop Distributor (membership bootstrap; nullifier and commitment patterns) +- [LP-0016](./LP-0016.md) and its [solution](../solutions/LP-0016.md) — anonymous membership proofs, N-of-M moderation certificates, K-strike Shamir slashing; the closest delivered analogue to this prize's deliberation layer +- [RFP-005 — Multisig and Coordination](https://github.com/logos-co/rfp/pull/113) — execution layer, coordination rooms, time locks, role separation, weighted approvals +- [`logos-co/forum-sample-app`](https://github.com/logos-co/forum-sample-app) — the forum stack this prize's deliberation surface may build on +- [`logos-co/logos-rln-modules`](https://github.com/logos-co/logos-rln-modules) — rate-limiting nullifiers, directly relevant to bounding anonymous proposal creation +- [SPEL framework](https://github.com/logos-co/spel) · [LEZ repo](https://github.com/logos-blockchain/logos-execution-zone) · [`cycle_bench`](https://github.com/logos-blockchain/logos-execution-zone/tree/dev/tools/cycle_bench) +- [LP-0023](./LP-0023.md) — LEZ Program Registry; reference for the adoption-first evidence standard + +**Private voting prior art** (surveyed in the draft private-voting appendix, [logos-co/rfp#156](https://github.com/logos-co/rfp/pull/156)) + +- [Penumbra governance](https://penumbra.zone/) — the surveyed system that most explicitly splits delegate transparency from delegator privacy, and the closest reference for this prize's central trade-off +- [Vocdoni DAVINCI](https://davinci.vote/) — never-decrypt zkRollup voting; threshold-homomorphic ElGamal with ZK ballot-validity proofs, the primitive the ecosystem is converging on +- [MACI](https://maci.pse.dev/) and the [MACI Aragon OSx plugin](https://github.com/aragon/zk-multisig-plugin) — coordinator-based collusion resistance, and the limits of it +- [Shutter shielded voting on Snapshot](https://blog.shutter.network/) — delayed reveal in production since 2022; useful as the boundary this prize asks submitters to argue past +- [Semaphore](https://semaphore.pse.dev/) — anonymous signalling primitive +- ["On-Chain Vote Buying and the Rise of Dark DAOs"](https://initc3org.medium.com/on-chain-vote-buying-and-the-rise-of-dark-daos-r5f6f36eb640) (Daian, Kell, Miers, Juels, IC3 2018) — receipt-freeness and coercion resistance +- ["DAO Decentralization: Voting-Bloc Entropy, Bribery, and Dark DAOs"](https://www.usenix.org/conference/usenixsecurity25) (USENIX Security 2025) — the working Dark DAO prototype +- [Nouns Private Voting Research Sprint](https://github.com/nouns-private-voting) — three funded designs, including Poseidon's explicit choice to keep voters public to preserve delegation + +## Potential for Subsequent λ Prizes + +This prize covers the **first adoption tranche** for private DAO governance. A follow-up λPrize is expected with higher thresholds adapted to the phase the network is in, and may extend into areas out of scope here: cross-DAO delegation and reputation, governance analytics that do not compromise ballot privacy, and formal receipt-freeness once a suitable primitive exists in the stack. + +If the private-voting and delegation layers are specified and delivered separately after this prize opens, a subsequent λ Prize may cover migrating the DAO app off its own reference backends onto them. + +--- + +**Note:** The Specification in this Prize describes an outcome that Logos intends to benefit the Logos ecosystem. It sets out criteria and certain requirements a Participant should fulfill in order to potentially be eligible to be awarded a Prize amount, and is not intended to be an instruction or to direct a Participant’s initiative or approach. They are guided by existing approaches and implementations in other mature blockchain systems and their ecosystems, as well as by functional requirements particular to the Logos technology stack or perceived usefulness to such stack or the wider community building on it. + +Logos makes no representation as to the legal or regulatory treatment of this Specification or any implementation of it in any jurisdiction. + +Participants act independently, voluntarily and at their own initiative in connection with their Submissions and are solely responsible for: + +1. assessing the risks and implications of their Participation in the Program and of any Artefacts that form part of their Submission; +2. determining whether to obtain independent professional advice; +3. complying with all applicable laws to them and in connection with the Program, including, where relevant, any licensing, registration, sanctions or anti-money laundering obligations that may arise from operating any software-as-a-service or business. + +Artefacts developed by Participants in connection with the Program are published and maintained by Participants and not by Logos or its Affiliates. Logos and its Affiliates do not build, host, maintain, deploy, operate, use or control any Artefacts arising out of any Submission. + +Participants or other persons who choose to build upon, host, maintain, deploy, operate, use or publicly promote any Artefacts, do so at their own risk and as a principal and in their own name. Any such persons are further solely responsible for complying with any legal or regulatory requirements that apply to them with such use. Logos does not make any representation, provide any advice or assume any responsibility regarding the use of such Artefacts, or any determination of compliance with applicable law or regulation. + +For further details of the above and what terms and conditions apply to a Participant, please refer to the [λPrize Program – Terms & Conditions](../TERMS.md). From f0fbe2b975c11f1d8270184b319885710ef04394 Mon Sep 17 00:00:00 2001 From: Sasha Date: Fri, 4 Sep 2026 01:50:58 +0200 Subject: [PATCH 2/3] update nubmer and open LP --- README.md | 2 +- prizes/{LP-0025.md => LP-0019.md} | 12 ++---------- 2 files changed, 3 insertions(+), 11 deletions(-) rename prizes/{LP-0025.md => LP-0019.md} (96%) diff --git a/README.md b/README.md index debeef7f..16fe9bae 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md)) | -| [LP-0025](prizes/LP-0025.md) | Private DAO: proposal lifecycle, deliberation, and delegation | Large | Draft | +| [LP-0019](prizes/LP-0019.md) | Private DAO: proposal lifecycle, deliberation, and delegation | Large | Open | ### Proposing a New Prize diff --git a/prizes/LP-0025.md b/prizes/LP-0019.md similarity index 96% rename from prizes/LP-0025.md rename to prizes/LP-0019.md index 22e0aea0..3e4fbff7 100644 --- a/prizes/LP-0025.md +++ b/prizes/LP-0019.md @@ -8,7 +8,7 @@ dependencies: reason: Multisig and Coordination — the execution layer. A passed proposal has to execute against a treasury or an admin authority, and RFP-005 is the M-of-N program (plus per-instance coordination room) this app is expected to drive. --- -# LP-0025: Private DAO — proposal lifecycle, deliberation, and voting-weight delegation [DRAFT] +# LP-0019: Private DAO — proposal lifecycle, deliberation, and voting-weight delegation [DRAFT] **`Status: Draft`** **`Logos Circle: N/A`** @@ -144,15 +144,7 @@ It is also the gap that makes the rest legible. A private multisig with no organ **Attested participation (member-side)** -- [ ] Across those proposals, at least **100 distinct members** cast a ballot, and at least **50 delegations** are in force from at least **30 distinct delegators** across at least **6 distinct delegates**, with no single delegate holding more than 40% of delegated weight in any DAO counted here. Supplied as governance attestations — proofs of the counts, not lists of the accounts. Attestations must be independently verifiable by an evaluator against on-chain state, and a DAO that can only supply these numbers by disclosing its membership roll does not satisfy this criterion. - -**Contested outcomes** - -- [ ] In at least 8 of the 30 proposals, the losing side carried 25% or more of participating weight. Governance that only ever ratifies is not evidence that anyone deliberated, and contested proposals are the only ones under which the privacy guarantees are load-bearing — they are where a member has something to lose by being seen voting. - -**Logos Circle adoption** - -- [ ] At least 2 Logos Circles use the deliverable to govern their own activity. For each: a named steward, a written statement of what it is used for and since when, and a re-confirmation at the T+3-month retention check. A Circle that has stopped using it does not count. +- [ ] Across those proposals, at least **50 distinct members** cast a ballot, and at least **25 delegations** are in force from at least **15 distinct delegators** across at least **3 distinct delegates**, with no single delegate holding more than 40% of delegated weight in any DAO counted here. Supplied as governance attestations — proofs of the counts, not lists of the accounts. Attestations must be independently verifiable by an evaluator against on-chain state, and a DAO that can only supply these numbers by disclosing its membership roll does not satisfy this criterion. **Continued use after the award** From 57600d18aad5170d5fdc7d1bc71054aadeed9e94 Mon Sep 17 00:00:00 2001 From: Sasha Date: Mon, 7 Sep 2026 14:54:18 +0200 Subject: [PATCH 3/3] address comments --- prizes/LP-0019.md | 46 ++++++++++++++++++---------------------------- 1 file changed, 18 insertions(+), 28 deletions(-) diff --git a/prizes/LP-0019.md b/prizes/LP-0019.md index 3e4fbff7..a79f2173 100644 --- a/prizes/LP-0019.md +++ b/prizes/LP-0019.md @@ -8,19 +8,16 @@ dependencies: reason: Multisig and Coordination — the execution layer. A passed proposal has to execute against a treasury or an admin authority, and RFP-005 is the M-of-N program (plus per-instance coordination room) this app is expected to drive. --- -# LP-0019: Private DAO — proposal lifecycle, deliberation, and voting-weight delegation [DRAFT] +# LP-0019: Private DAO — proposal lifecycle, deliberation, and voting-weight delegation [OPEN] -**`Status: Draft`** **`Logos Circle: N/A`** ## Overview -A DAO is not a voting contract. It is a loop: someone raises a proposal, members argue about it, members vote on it, and — if it passes — something executes against a treasury or an admin authority. Logos has, or is building, a component for each of those steps. What does not exist is the thing that makes them one organisation. +A DAO is not a voting contract. It is a loop: someone raises a proposal, members argue about it, members vote on it, and — if it passes — something executes against a treasury or an admin authority. Logos is building infrastructure that enables those components. What does not exist is the thing that makes them one organisation. This prize funds a **Private DAO app for Logos Basecamp**: the proposal lifecycle that carries a decision from draft to execution, the deliberation surface bound to each proposal, private voting with member-held weight, and voting-weight delegation — with a privacy boundary that holds *across* those steps rather than inside each one. -The hard part is not any single layer. It is the seams. A ballot cast privately still leaks if the deliberation thread beside it is attributable, if the weight it carries is unique, or if the execution that follows names the members who authorised it. And delegation — the mechanism every large DAO relies on to get turnout at all — is in direct structural tension with ballot privacy. A submission has to take a position on that tension and defend it, not paper over it. - ## Motivation ### Public governance is the norm, and it is measurably distorted @@ -35,7 +32,7 @@ The measured consequences of that design: ### Delegation is where privacy and accountability collide -Delegation is not a side feature. It is how large DAOs reach quorum at all — and it consolidates rather than disperses influence. Across ENS, Uniswap, Compound and Aave, voting-power Gini sits at 0.94–0.99; ENS's Nakamoto coefficient is **1**, meaning a single delegate holds a majority of participating power. +Delegation is not a side feature. It is how large DAOs reach quorum at all — and it consolidates rather than disperses influence. Across ENS, Uniswap, Compound and Aave, almost all voting power sits with a handful of delegates. In ENS, a single delegate holds a majority of the votes that actually participate. Delegated governance also *institutionalises* public voting. Uniswap's DAO Principles (Proposal 78, January 2025) require delegates to publish vote rationales and disclose conflicts; the Delegate Reward Initiative attaches payment to a seven-day rationale deadline; Optimism and Arbitrum publish comparable expectations. A delegate who cannot be seen voting cannot be held accountable — and a member who can be seen voting can be coerced. @@ -55,25 +52,23 @@ It is also the gap that makes the rest legible. A private multisig with no organ **Proposal lifecycle** -- [ ] A member can create a proposal carrying, at minimum: a title, a body, the executable action it authorises (target program and decoded instruction), a voting window, and the quorum and passing thresholds in force. Proposal states are explicit and enforced by the program, not by client convention: `draft → deliberation → voting → passed | failed → (time lock) → executed | expired`, plus `cancelled`. +- [ ] A member can create a proposal. - [ ] **Voting weight is snapshotted** at the transition into `voting`. Weight acquired, transferred, or delegated after the snapshot does not count toward that proposal. - [ ] **Anonymous proposal spam is bounded.** Under unlinkable membership, an eligibility proof alone permits unlimited proposals. Submissions must bound proposal creation — a per-epoch rate-limiting nullifier, a refundable deposit, a proposal-weight threshold, or an equivalent — without deanonymising the proposer. The chosen mechanism must be enforced on-chain or by the verifying program, not by the UI. - [ ] A proposal that fails quorum, fails its threshold, or expires unexecuted terminates in a state the program will not execute from. **Voting** -- [ ] A member casts a ballot carrying their snapshotted weight without revealing, to any observer including the tallier, which member they are or how they voted. -- [ ] **Double-voting is prevented cryptographically** — nullifiers or equivalent — including across the direct/delegated boundary (below). -- [ ] **Quorum and thresholds are proven over hidden weights.** The result publishes the aggregate; the tally proves that participating weight met quorum and that the passing threshold was reached, without publishing per-ballot weight. Where the design leaks weight (a ballot revealing its own magnitude, for example), that leak must be stated and quantified, not assumed harmless. -- [ ] **Governance attestation.** A DAO can produce a verifiable statement about its own governance — at minimum the number of distinct members who voted on a proposal, the number of distinct delegators and delegates in force at snapshot, and that no weight was double-counted — **without revealing which members those were**. This is what lets a private DAO demonstrate legitimacy to an outsider (a grant funder, a counterparty, an evaluator) instead of asking to be trusted, and it is the mechanism the Adoption section below is evidenced against. -- [ ] The submission states which privacy boundary it implements — **delayed reveal** (ballots published after voting closes) or **never-decrypt** (only the aggregate ever opens) — and why. Only the latter defends against retaliation, coercion, or post-hoc vote buying; a delayed-reveal design must argue explicitly why that is acceptable for its target user. +- [ ] A member casts a ballot carrying their snapshotted weight. Ballots are not publicly attributable to a member. +- [ ] Double-voting is prevented, including across the direct/delegated boundary, and is enforced by the program — not by the client or the tallier. +- [ ] A proposal's result can be checked against the quorum and passing threshold in force at snapshot. What the tally publishes (aggregates, weights, identities) is a submitter choice. +- [ ] The submission states and implements its voting privacy position — who learns identity, choice, and weight, and when. **Delegation** - [ ] A member can delegate their voting weight to another member, change that delegation, and revoke it. Delegation takes effect no later than the next proposal snapshot. -- [ ] **Direct votes and delegated weight cannot double-count.** If a delegating member votes directly on a proposal, exactly one of the two ballots counts, and which one is defined by the protocol and enforced by the verifier — not resolved by the client or by tallier discretion. -- [ ] **The delegation privacy position is explicit and enforced.** The submission must state, and implement, who can see what: whether a delegate's votes are attributable (accountability, Uniswap/Optimism/Arbitrum-style) or private (coercion resistance), and whether the delegation edge itself — *who delegated to whom* — is public, private, or private-with-leakage. Silence on any of the three is a failing answer; a defended trade-off is a passing one. -- [ ] **Delegation does not silently collapse the anonymity set.** The submission must document how small delegate cohorts affect member privacy (a delegate with one delegator identifies that delegator's weight) and what the implementation does about it. +- [ ] Direct votes and delegated weight cannot both count on the same proposal. Which one counts is defined by the protocol and enforced by the program — not by the client or the tallier. +- [ ] The submission states and implements who can see delegate votes and who can see the delegation graph. A defended trade-off passes; silence fails. **Deliberation** @@ -89,8 +84,7 @@ It is also the gap that makes the rest legible. A private multisig with no organ **Composition boundary** -- [ ] **Execution is behind a documented adapter.** A passed proposal executes through an execution backend the DAO app does not itself implement. The app must define that interface and ship at least one working backend. If the RFP-005 multisig is available at submission time, it must be the primary backend; otherwise the submission ships a minimal reference backend and demonstrates the adapter by swapping it. Hard-coupling the lifecycle to one execution implementation does not satisfy this criterion. -- [ ] The same applies to voting and deliberation: each is reached through an interface with at least one working implementation, so a component delivered later (a private-voting primitive, forum v0.2+) can replace the submission's own without rewriting the lifecycle. +- [ ] The submission defines explicit APIs between lifecycle, voting, deliberation, and execution so any of them can be upgraded, replaced, or customised later. Each API ships with at least one working implementation. If the RFP-005 multisig is available at submission time, it is the execution implementation; otherwise a minimal reference backend is enough. **Cross-layer privacy accounting** @@ -99,11 +93,11 @@ It is also the gap that makes the rest legible. A private multisig with no organ ### Usability -- [ ] A Logos Basecamp app covering the full member journey — join, delegate, propose, deliberate, vote, watch a result execute — usable without CLI interaction or manual transaction crafting. -- [ ] An SDK/module with a documented API, so another Logos app can drive the lifecycle without embedding this app's UI. +- [ ] Core logic created as Logos module(s) with documented API, so another Logos app can drive the lifecycle without embedding this app's UI. +- [ ] A Logos Basecamp UI app built using Logos modules with core logic and covering the full member journey — join, delegate, propose, deliberate, vote, watch a result execute — usable without CLI interaction or manual transaction crafting. - [ ] Before a member votes, the app displays the exact action the proposal authorises — target program, decoded instruction, amounts — rather than a UI-rendered summary. - [ ] An IDL for every LEZ program delivered, using the [SPEL framework](https://github.com/logos-co/spel). -- [ ] The privacy posture is legible in the UI: at each action a member can see what that action publishes. A member should not have to read the threat model to learn that delegating is visible. +- [ ] The privacy posture is legible in the UI: at each action a member can see what that action publishes. ### Reliability @@ -115,13 +109,13 @@ It is also the gap that makes the rest legible. A private multisig with no organ ### Performance -- [ ] Ballot proof generation completes in **under 10 seconds** on a standard laptop, matching the bar set by LP-0016. +- [ ] Ballot proof generation completes in **under 10 minutes** on a standard laptop, matching the bar set by LP-0016. - [ ] Tally verification cost is documented **as a function of member count and of participating-weight distribution**, with the largest DAO size that remains viable within LEZ block limits reported. If the viable ceiling is small, that finding is a reportable result rather than something to be silently shipped around. - [ ] Compute-unit / cycle counts documented for every on-chain operation (DAO creation, membership change, delegation, ballot submission if on-chain, tally, execution), benchmarked with **real proving** (`RISC0_DEV_MODE=0`). Development-mode figures are not accepted. ### Supportability -- [ ] Deployed and tested against the current Logos testnet; the targeted version is stated. +- [ ] Deployed and tested against the current Logos testnet v0.3. - [ ] Builds and runs end-to-end on **macOS (Apple Silicon)** and **Linux (x86_64)**. - [ ] The Logos Core module is built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) and published to a module catalog ([`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base) fork), with the `logos-repo.json` URL supplied so evaluators can install it through the package-manager UI / `lgpd`. - [ ] End-to-end integration tests covering the full lifecycle run against a LEZ sequencer in standalone mode and are included in CI; CI green on the default branch. @@ -138,17 +132,13 @@ It is also the gap that makes the rest legible. A private multisig with no organ **On-chain activity (operator-side)** -- [ ] 10 DAOs created on the official Logos zone carrying this submission's identifier, from at least 10 distinct operator accounts independent of each other and of the submitting team. Accounts with no prior unrelated testnet activity carry little weight; accounts created in a burst around the submission date do not count. +- [ ] 5 DAOs created on the official Logos zone carrying this submission's identifier, from at least 5 distinct operator accounts independent of each other and of the submitting team. Accounts with no prior unrelated testnet activity carry little weight; accounts created in a burst around the submission date do not count. - [ ] 30 proposals reach a terminal state — deliberated, voted, and either executed or terminally failed at quorum or threshold. Proposals created and abandoned do not count. **At least 10 must have executed an action** against a treasury or an admin authority. - [ ] The 30 proposals are spread over at least 2 months, with at least 10 in each of those months. A single burst does not qualify, however large. **Attested participation (member-side)** -- [ ] Across those proposals, at least **50 distinct members** cast a ballot, and at least **25 delegations** are in force from at least **15 distinct delegators** across at least **3 distinct delegates**, with no single delegate holding more than 40% of delegated weight in any DAO counted here. Supplied as governance attestations — proofs of the counts, not lists of the accounts. Attestations must be independently verifiable by an evaluator against on-chain state, and a DAO that can only supply these numbers by disclosing its membership roll does not satisfy this criterion. - -**Continued use after the award** - -- [ ] At least 10 reproducible issues were opened by people outside the submitting team and resolved, with a linked fix. Median first response under 7 days over the observation window. +- [ ] Across those proposals, at least **50 distinct members** cast a ballot, and delegation is in use (at least one live delegation). Supplied as governance attestations — proofs of the counts, not lists of the accounts. Attestations must be independently verifiable by an evaluator against on-chain state, and a DAO that can only supply these numbers by disclosing its membership roll does not satisfy this criterion. **Discretionary**