From f70101c06c5ee13074e084cb379e4e79b23e41cb Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 8 Jul 2026 13:02:36 +1000 Subject: [PATCH 01/14] RFP-005: Multisig and Coordination + ecosystem appendix Add the Multisig and Coordination RFP and its ecosystem-behaviour appendix, and register RFP-005 in the README index. The appendix (facts and observations only, product angle) leads with a data inventory: the ten distinct data/metadata items a multisig involves, whether each could be private on LEZ, and what existing multisigs (Safe, Squads, ERC-4337, Bitcoin script, FROST) do with it. It then covers the LEE public/private account model, the quorum-privacy spectrum, coordination channels and what each leaks, roles/policies, composition, and hardware support. Sourced from the research-multisig-sovereign vault. The RFP hardens the existing public multisig sample app (logos-co/lez-multisig) into production, adds an end-to-end-encrypted per-multisig coordination room via the Logos chat module, and ends with three A/B/C decisions for review: privacy posture, coordination channel, and quorum-model baseline. Co-Authored-By: Claude Opus 4.8 --- README.md | 1 + RFPs/RFP-005-multisig-and-coordination.md | 412 ++++++++++++++++++++ appendix/multisig-coordination-ecosystem.md | 389 ++++++++++++++++++ 3 files changed, 802 insertions(+) create mode 100644 RFPs/RFP-005-multisig-and-coordination.md create mode 100644 appendix/multisig-coordination-ecosystem.md diff --git a/README.md b/README.md index 25704e65..3de5cb3c 100644 --- a/README.md +++ b/README.md @@ -80,6 +80,7 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | closed | Developer Tooling & Infrastructure | Closed | | RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | closed | Applications & Integrations | Closed | | RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | closed | Applications & Integrations | Closed | +| RFP-005 | [Multisig and Coordination](RFPs/RFP-005-multisig-and-coordination.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | closed | Applications & Integrations | Closed | diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md new file mode 100644 index 00000000..3b075c93 --- /dev/null +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -0,0 +1,412 @@ +--- +id: RFP-005 +title: Multisig and Coordination +tier: L +funding: $XXXXX +status: open +dependencies: + - id: LP-0002 + reason: Private M-of-N multisig sample-app proof; establishes the private-account multisig design this RFP hardens to production. + - id: SA-public-multisig + reason: The public multisig sample app (logos-co/lez-multisig) is the transparent baseline whose proposal→approve→execute→ChainedCall design this RFP builds on. + - id: RD-chat + reason: The Logos chat module provides the end-to-end-encrypted, metadata-resistant coordination channel required per multisig for signer deliberation and, optionally, signing-material transport. +category: Applications & Integrations +--- + +# RFP-005 — Multisig and Coordination + +## 🧭 Overview + +Build a production-ready M-of-N multisig program on the Logos Execution Zone +(LEZ), together with an in-band coordination channel so signers can deliberate +and reach quorum without leaving the application. A multisig is the execution +layer for shared custody, treasuries, and DAOs: the Logos launch-day Private +Multisig app and the Private DAO both depend on it. A public multisig sample app +already exists on LEZ (`logos-co/lez-multisig`, inspired by Squads Protocol v4): +proposals live on-chain, signers approve asynchronously, and execution delegates +to any LEZ program via `ChainedCall`. This RFP hardens that prototype into a +production program and adds the properties LEZ makes uniquely possible: multisig +state that can be kept private, and a coordination channel that is encrypted and +metadata-resistant. + +Multisig is the single most widely used custody primitive in the ecosystem. On +Ethereum, Safe (formerly Gnosis Safe) is the dominant standard, deployed across +86 networks; on Solana, Squads is the analogue. Both are fully transparent by +construction: members, threshold, every approval, and every action are public +on-chain state, because the chain must read the quorum in order to enforce it. +That transparency has been an attack surface: the Bybit (February 2025, +~US$1.5B) and WazirX (July 2024, ~US$235M) incidents both targeted fully visible +Safe configurations at the signing layer. + +The team building this should have deep experience in multisig or threshold +custody design, Rust program development for a RISC-V or zkVM target, and +applied cryptography. + +## 🔥 Why This Matters + +Shared custody is a precondition for organisations to operate on Logos. Without +a production multisig, there is no treasury, no DAO execution layer, and no +shared control of protocol admin authorities. The launch-day Private Multisig +app (`A-multisig`) and the Private DAO (`LD-private-dao`) are blocked on it. + +LEZ also makes it possible to close a gap no sovereign multisig has closed. As +the [appendix](../appendix/multisig-coordination-ecosystem.md) documents, every +existing implementation that keeps multisig structure private (FROST, MuSig2 +n-of-n) does so by moving the quorum off-chain into a cryptographic session, at +the cost of hardware immaturity and, for MuSig2, an n-of-n-only limitation. +Every implementation that keeps the quorum on-chain is transparent. On LEZ, the +same multisig program can run over private accounts, so the chain records only a +commitment to the post-state and a validity proof, without a trusted coordinator +and without giving up k-of-n. This RFP is the vehicle for delivering that. + +## ✅ Scope of Work + +### Hard Requirements + +#### Functionality + +1. Implement an M-of-N multisig program on LEZ. A multisig is created with N + members and a threshold M; an action requires at least M approvals before it + can execute. Members, threshold, and the action set are configurable at + creation. +2. Support the full proposal lifecycle: a member proposes an action; members + approve or reject asynchronously; once M approvals are collected the action + becomes executable; if rejections make M approvals impossible the proposal is + dead. Support proposal cancellation before execution and proposal expiry. +3. Execute approved actions by delegating to any LEZ program via `ChainedCall`, + following the existing `logos-co/lez-multisig` design: the proposal stores a + serialised instruction and target program ID, and execution delivers it to + the target. The multisig never modifies external state directly. See + [Appendix section 6](../appendix/multisig-coordination-ecosystem.md#6-composition-how-a-multisig-triggers-actions). +4. Support configuration changes (add or remove a member, change the threshold) + through the same M-of-N approval flow, so structural changes cannot bypass + the quorum. +5. Support role separation among members so that the ability to propose, to + approve, and to execute can be assigned independently, following the Squads + permission model documented in + [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). + At minimum, a proposing key need not be an approving key. +6. Support an optional per-multisig time lock: a configurable delay between an + action reaching quorum and becoming executable, enforced by the program. A + time lock of zero means immediate execution. +7. Support an optional spending-limit policy: a member (or sub-quorum) may + execute transfers up to a configured limit without the full M-of-N approval, + per the policy model in + [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). +8. Provision an end-to-end-encrypted coordination room per multisig using the + Logos chat module (RD-chat), scoped to the multisig's members, for signer + deliberation. See the Coordination Architecture section for what this channel + carries and its privacy properties. +9. Support the privacy posture selected under Decision 1 (see Decisions for + Review). The program must run the multisig over the account kind(s) required + by that posture (public accounts, private accounts, or both) so that the data + items designated private in Decision 1 are not published on-chain. See + [Appendix section 1](../appendix/multisig-coordination-ecosystem.md#1-what-data-a-multisig-involves-and-whether-it-can-be-private) + and + [section 2](../appendix/multisig-coordination-ecosystem.md#2-the-lee-execution-model-public-vs-private-accounts). + +#### Usability + +1. Provide an SDK that can be used to build Logos modules for interacting with + the multisig (create, propose, approve, reject, execute, manage members and + policies). +2. Provide a Logos mini-app GUI with local build instructions, downloadable + assets, and loadable in Logos app (Basecamp) via git repo. The mini-app must + surface the per-multisig coordination room alongside the proposal list. +3. Provide a CLI that covers core functionality of the program (create, propose, + approve, reject, execute, and configuration changes). The CLI may have fewer + features than the GUI mini-app but must support all essential operations. +4. Provide an IDL for the LEZ program, preferably using the + [SPEL framework](https://github.com/logos-co/spel). +5. Documentation must clearly explain, for each action, what information is + public and what is private under the selected privacy posture (which data + items from Appendix section 1 are published on-chain and which are not), so a + multisig operator understands exactly what an observer can see. +6. Before a member signs an approval, the mini-app must display the exact action + that approval authorises (target program, decoded instruction, amounts), so + the member verifies what they are signing rather than a UI-rendered summary. + This directly addresses the signing-layer attack surface described in + [Appendix section 1.2](../appendix/multisig-coordination-ecosystem.md#12-approval-attribution-and-pending-proposals-items-4-5). +7. Failed or rejected proposals and executions must return clear, actionable + error messages. + +#### Reliability + +1. Multisig state must remain consistent under concurrent approvals from + different members; no approval is lost or double-counted, and an action + cannot execute with fewer than M valid approvals. +2. A configuration change (member set or threshold) must invalidate in-flight + proposals whose approval set was gathered under the old configuration, unless + they had already reached quorum, following the stale-proposal handling in + [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). + +#### Performance + +1. Each operation (create, propose, approve, reject, execute) completes within a + single LEZ transaction. +2. Compute unit usage and transaction size of each operation must be documented + and benchmarked against LEZ devnet limits. If the selected privacy posture + uses private-account execution, the per-proof cost and the per-block private + transaction throughput must be measured and reported, since they bound how + many approvals can be processed per block. + +#### Supportability + +1. The multisig program is deployed and tested on LEZ devnet/testnet. +2. End-to-end integration tests run against a LEZ sequencer (standalone mode) + and are included in CI. +3. CI must be green on the default branch. +4. Every hard requirement in Functionality, Usability, Reliability, and + Performance has at least one corresponding test, including a test that an + action cannot execute below threshold and a test that a configuration change + respects requirement R.2. +5. A README documents end-to-end usage: deployment steps, program addresses, and + step-by-step instructions for creating a multisig, proposing, approving, and + executing via CLI and front-end, including how the coordination room is + provisioned. +6. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the SDK, covering the developer integration journey. +7. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the CLI, covering the core operator journey. +8. Provide Figma designs or equivalent for the mini-app GUI, including the + proposal list and the coordination room. + +### Soft Requirements + +If possible. + +#### Functionality + +1. Support batch proposals: a single proposal covering multiple actions that are + approved once and executed atomically or in sequence, per the Squads batch + model in + [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). +2. Support weighted approvals, where members carry numeric weights and the + threshold is a minimum cumulative weight, per + [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). + +### Out of Scope + +The following are explicitly excluded from this RFP: + +- A FROST or MuSig2 threshold-signature implementation. Structural privacy on + LEZ is achieved through private-account execution (Appendix section 2), not + through an off-chain threshold-signature session. Threshold-signature schemes + are documented in the appendix as ecosystem context only. +- Recovery of a multisig whose members have lost quorum-many keys. Social or + time-locked key recovery is a separate concern and is not required here. + +### Coordination Architecture + +Every multisig provisions one end-to-end-encrypted room using the Logos chat +module (RD-chat), scoped to its members. As the +[appendix](../appendix/multisig-coordination-ecosystem.md#4-coordination-how-signers-reach-quorum) +documents, no surveyed sovereign multisig offers an encrypted, +metadata-resistant coordination channel: coordination today is either public +on-chain state (Squads), a relay that sees the metadata (Safe), or a +user-supplied external channel (Bitcoin). The Logos chat module closes that gap. + +What the room carries, and whether machine coordination (proposals and +approvals) also flows through it or stays as on-chain state, is the subject of +Decision 2 (see Decisions for Review). In all variants the room carries human +deliberation: the discussion among signers about whether to approve. The room is +coordination, not enforcement: quorum is always enforced by the program +on-chain, never by the chat channel. + +### Privacy Architecture + +A multisig involves at least ten distinct data and metadata items, enumerated in +[Appendix section 1](../appendix/multisig-coordination-ecosystem.md#1-what-data-a-multisig-involves-and-whether-it-can-be-private): +the existence of the multisig, the member set, the threshold, per-signer +approval attribution, pending-proposal metadata, the action payload, the vault +balance, execution linkage, coordination content, and the co-signing social +graph. On LEZ, each of these can independently be public or private, because the +Logos Execution Environment runs the same program over public accounts (visible +on-chain) or private accounts (only a post-state commitment and validity proof +on-chain), per +[Appendix section 2](../appendix/multisig-coordination-ecosystem.md#2-the-lee-execution-model-public-vs-private-accounts). + +Which of these items must be private, which are left to the operator's choice, +and which are private by default with a public opt-out, is the subject of +Decision 1 (see Decisions for Review). Where identity is concerned, the property +in question is unlinkability between a user's account and its role in a +multisig, not concealment of the user. Documentation (Usability requirement U.5) +must state the resulting public/private split explicitly for the chosen posture. + +## ⚠ Platform Dependencies + +This RFP is open for proposals. Proposers may begin design and development work, +but a working on-chain deployment depends on the primitives below. + +### Hard blockers + +#### Private-account execution (core LEE feature) + +If the selected privacy posture (Decision 1) requires any multisig data to be +private, the program relies on LEE private accounts: post-state commitments, +nullifiers, and Risc0 validity proofs, as described in +[Appendix section 2](../appendix/multisig-coordination-ecosystem.md#2-the-lee-execution-model-public-vs-private-accounts). +These are core LEE features rather than lambda prizes; proposers should confirm +the current state of private-account support on LEZ devnet against the Resources +below before relying on it, including whether program-derived private accounts +are supported for the multisig's vault. + +#### Logos chat module (RD-chat) + +The per-multisig coordination room (Functionality requirement F.8) depends on +the Logos chat module, tracked as `RD-chat`. Proposers should confirm the +module's availability and its SDK surface for creating a member-scoped, +end-to-end-encrypted room before relying on it. + +### Resolved dependencies + +#### Cross-program calls via ChainedCall + +Execution delegates to a target program via `ChainedCall` (Functionality +requirement F.3). This is the mechanism the existing `logos-co/lez-multisig` +sample app already uses, delivered by the LEZ team as part of the core runtime. + +### Risks + +#### Private-transaction throughput + +If the privacy posture uses private-account execution, each approval that +mutates private state produces a proof and consumes a private-transaction slot. +LEZ private-transaction throughput per block is limited (as of 2026-04, one +private transaction per block on the reference deployment); a multisig with many +members approving in quick succession may be bounded by this. Performance +requirement P.2 requires this to be measured and reported. If throughput is a +constraint, the proposal should describe how approvals are batched or +aggregated. + +#### Signing-layer trust + +As the appendix records, the Bybit and WazirX losses were not smart-contract +failures; they exploited the gap between what a signer saw in a UI and what they +actually authorised. Usability requirement U.6 (show the exact decoded action +before signing) is the primary mitigation and must not be treated as optional +polish. + +## 👤 Recommended Team Profile + +Team experienced with: + +- Multisig, threshold custody, or account-abstraction design +- Rust program development for a RISC-V or zkVM target (Risc0 experience a plus) +- Applied cryptography and zero-knowledge proof systems +- Secure signing UX and hardware-wallet integration +- Front-end development for custody or wallet applications + +## ⏱ Timeline Expectations + +Estimated duration: **12 weeks** (production-hardening of the proven +`lez-multisig` design, plus the coordination room and the selected privacy +posture). The estimate assumes the privacy posture is settled at contracting +time via Decision 1; a posture requiring private-account execution of the full +proposal lifecycle sits at the upper end of the range. + +## 🌍 Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. + +## Resources + +- [Logos Documentation](https://github.com/logos-co/logos-docs) +- [logos-co/lez-multisig](https://github.com/logos-co/lez-multisig): the + existing public multisig sample app this RFP hardens +- [Introduction to the Logos Execution Zone](https://docs.logos.co/lez): the + public/private account model this RFP relies on + +## 🧩 Decisions for Review + +The following three decisions shape the deliverable and should be settled before +contracting. Each is presented as options A / B / C with the trade-offs drawn +from the [appendix](../appendix/multisig-coordination-ecosystem.md). A +recommended default is marked, but the choice is open. + +### Decision 1 — Privacy posture: which multisig data is private? + +Per Appendix section 1, a multisig involves ten distinct data items, each of +which can independently be public or private on LEZ. This decision sets, per +item, whether privacy is mandatory, operator-selectable, or default-on. + +- **Option A — Public multisig (transparent, like Safe/Squads).** All ten data + items are public. Simplest to build and audit; matches the existing + `lez-multisig` sample app; gives the transparent, publicly-inspectable + behaviour some treasuries and DAOs want. But it carries the same + transparency-as-attack- surface profile as Safe and Squads, and delivers none + of the LEZ privacy advantage. +- **Option B — Operator choice per multisig (recommended default).** The program + supports both public and private execution; at creation the operator chooses + the posture. A recommended default configuration is shipped (see below). + Maximises fitness across use cases (a transparent DAO treasury and a private + company multisig from the same program) at the cost of building and testing + both execution paths. Recommended default within this option: existence, + member set, approval attribution, action, execution linkage, and social graph + **private**; coordination content **always private** (E2EE room); threshold, + pending-proposal visibility, and holdings **operator-selectable**. +- **Option C — Private-by-default multisig.** All items that can be private are + private by default, with a per-item public opt-out. Leans hardest into the LEZ + differentiator and gives the strongest default privacy, but every deployment + pays the private-execution cost (proof generation, throughput limits per + Appendix section 2 and the Risk above) even where an operator did not need it. + +### Decision 2 — Coordination channel: where do approvals flow? + +Per Appendix sections 1.2 and 4, machine coordination (proposals and approvals) +can live as on-chain state or off-chain, while human deliberation is always +off-chain. This decision sets where each flows. In all options, quorum is +enforced on-chain by the program. + +- **Option A — On-chain approvals + E2EE deliberation room (recommended + default).** Proposals and approvals are program state on-chain (public, or + private per Decision 1); the E2EE room carries human deliberation only. Keeps + a clean, program-enforced approval record and a live pending view, exactly as + `lez-multisig` does today, while adding the encrypted discussion channel no + competitor offers. Note (per Appendix section 1.2) this on-chain record is not + an audit-trail advantage over off-chain collection; both yield a record at + execution. Its value here is a simple, verifiable machine channel. +- **Option B — Approvals carried through the E2EE room.** The room is both the + deliberation channel and the transport for signing material; the program + verifies the collected approvals at execution (the Safe off-chain-collection + shape, but over an encrypted, metadata-resistant channel). Removes + per-approval on-chain writes and hides pending-proposal metadata even in a + public posture, at the cost of a more complex client that must reliably gather + and present approvals, and no live on-chain pending view. +- **Option C — Both, operator-selectable.** Ship both channels and let the + operator choose per multisig. Most flexible; largest client surface to build + and test. + +### Decision 3 — Quorum model baseline + +Per Appendix sections 2 and 3, structural privacy on LEZ comes from +private-account execution of an account-model multisig, not from a +threshold-signature scheme. This decision confirms the baseline the program is +built on. + +- **Option A — Account-model quorum on LEZ, hardening `lez-multisig` + (recommended default).** Members and threshold are program state; approvals + are program-verified; privacy (if selected) comes from running over private + accounts. Direct continuation of the proven sample app; the appendix shows + this is the only surveyed path to private, coordinator-free, k-of-n multisig. +- **Option B — Threshold signatures (FROST-style), single aggregate signature + on-chain.** Maximal structural privacy at the signature layer, but the + appendix documents FROST as BIP-draft, hardware-immature, and (for MuSig2) + n-of-n only; this is why it is Out of Scope above. Listed for completeness; + not recommended. +- **Option C — Deliver the account model now, keep a threshold-signature variant + as a documented future extension.** Build Option A, and specify the interface + seam where a threshold-signature signing path could be added later without + redesign. + +## ✏️ How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, please use +**Discussions**. diff --git a/appendix/multisig-coordination-ecosystem.md b/appendix/multisig-coordination-ecosystem.md new file mode 100644 index 00000000..4d84e14c --- /dev/null +++ b/appendix/multisig-coordination-ecosystem.md @@ -0,0 +1,389 @@ +# Appendix: Multisig and Coordination Ecosystem Behaviour + +This appendix surveys how existing multisig implementations across the Bitcoin, +Ethereum, and Solana ecosystems behave, with a focus on a single product +question: **what data does a multisig involve, and which parts of it are visible +to the outside world?** It is written from a product angle (what an operator, a +counterparty, or a passive observer can and cannot see), not a +contract-internals angle. + +All data is sourced from the +[research-multisig-sovereign](https://github.com/marclawclaw/research-multisig-sovereign) +vault; individual subject and pattern notes contain full citations. Access date +for all figures is 2026-07-06 unless otherwise noted. + +This appendix contains facts and observations only. It does not state +requirements, and it does not decide which data *should* be private for a Logos +multisig: that is the subject of +[RFP-005](../RFPs/RFP-005-multisig-and-coordination.md). + +## Protocols considered + +Nine implementations were studied, spanning the on-chain program layer and the +coordinator/UI layer across three ecosystems. Adoption is measured by GitHub +stars: multisig software holds assets in custody accounts rather than a DeFi +liquidity pool, so total-value-locked (TVL) is not an applicable metric, and no +authoritative TVL figure is published for the custody layer. + +| Implementation | Ecosystem / Layer | Stars | Last commit | Licence | +| --------------------------------------------------------------- | ------------------------------ | -------- | ----------- | --------------------------- | +| Bitcoin native script multisig (P2SH / P2WSH), via rust-bitcoin | Bitcoin / on-chain library | 2,641 | 2026-07-05 | CC0-1.0 | +| FROST threshold signatures, via Frostsnap | Bitcoin / threshold-sig | 147 | 2026-07-06 | MIT | +| Sparrow Wallet | Bitcoin / coordinator UI | 2,029 | 2026-07-04 | Apache 2.0 | +| Specter Desktop | Bitcoin / coordinator server | 838 | 2026-06-30 | MIT | +| Safe (Gnosis Safe) smart account | Ethereum / on-chain program | 2,165 | 2026-06-05 | LGPL-3.0-only | +| Safe self-hosted stack (UI + relay + CLI) | Ethereum / coordinator stack | 576 (UI) | 2026-07-03 | GPL-3.0 / MIT / FSL-1.1-MIT | +| ERC-4337 smart account, via ZeroDev Kernel | Ethereum / account abstraction | 247 | 2026-06-30 | MIT | +| Squads smart-account-program (v4) | Solana / on-chain program | 42 | 2026-05-25 | AGPL-3.0 | +| Squads v4 public UI | Solana / coordinator UI | 30 | 2025-03-06 | MIT | + +## 1. What data a multisig involves, and whether it can be private + +A multisig is not a single secret; it is a collection of distinct data and +metadata items, each of which can be independently visible or hidden. The table +below enumerates those items. For each, it records whether that item **could** +be kept private on the Logos Execution Zone (LEZ), and what existing multisig +implementations do with it today. + +"Could be private on LEZ" refers to the native execution model of the Logos +Execution Environment (LEE), described in section 2: the same program can run +over public accounts (visible on-chain) or private accounts (only a commitment +to the post-state is published). It states a capability of the platform, not a +recommendation. + +Where identity is concerned, the precise property is **unlinkability between a +user's account and its role in a multisig**, not "hiding a user's identity." A +signer always has an account; what can be made private is the *link* between +that account and the fact that it holds a signer or admin role in a specific +multisig. + +| # | Data / metadata item | Could be private on LEZ? | What existing multisigs do | +| --- | ---------------------------------------------------------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 1 | Existence: that an account acts as a multisig at all | Yes | Safe, Squads, ERC-4337: always public (the account is visibly a multisig contract/PDA). FROST and MuSig2 n-of-n: hidden (indistinguishable from a single-key account). | +| 2 | Member set: which accounts are signers (account↔signer-role link) | Yes | Safe, Squads, ERC-4337: always public (signer accounts are on-chain state). Bitcoin script: public keys revealed at spend. FROST / MuSig2: hidden. | +| 3 | Threshold configuration: the M and N of M-of-N | Yes | Safe, Squads, ERC-4337: always public. Bitcoin script: revealed at spend. FROST / MuSig2: hidden. | +| 4 | Approval attribution: which signer approved a given action (account↔approval link) | Yes | Squads: always public (each approval is separate on-chain state). Safe: revealed in the executing transaction, or earlier via on-chain `approveHash`. FROST / MuSig2: hidden (no per-signer trace survives). | +| 5 | Pending proposal: that an action is proposed and awaiting quorum, plus its metadata | Yes | Squads: always public (a pending proposal is a live on-chain account). Safe: typically off-chain until execution; the relay operator running the transaction service sees it. | +| 6 | Action payload: the target, calldata, and amounts being executed | Yes | Safe, Squads, ERC-4337: public at execution. Bitcoin: outputs and amounts public on-chain. | +| 7 | Holdings: the balance held by the multisig's vault | Yes | Safe, Squads, ERC-4337: always public (balances are on-chain state). Bitcoin: public per-UTXO, pseudonymous. | +| 8 | Execution linkage: that a given on-chain effect originated from this multisig (multisig↔effect link) | Yes | Safe, Squads, ERC-4337: public (the effect is a transaction from the multisig account). Bitcoin: linkable via the spending input. | +| 9 | Coordination content: the discussion and signing messages exchanged between signers | Yes (off-chain by nature) | No researched on-chain multisig addresses this. Safe's transaction service leaks proposal metadata to whoever runs the relay. Bitcoin coordinators use an external channel (email, SD card, QR). | +| 10 | Co-signing social graph: that this set of accounts jointly administers a multisig | Yes | Not addressed by any researched multisig. On account-model chains it is directly readable from the on-chain signer set (item 2); on Bitcoin it is inferable at spend. | + +The prose below explains each item's cross-ecosystem behaviour precisely. + +### 1.1 Existence, members, threshold (items 1-3) + +On the account-model chains, these three items are inseparable from how the +quorum is enforced. Safe stores its owner set as a linked list and its threshold +as a storage slot; Squads stores its members and threshold in a settings +account; ZeroDev Kernel stores guardian addresses and weights in contract +storage. In all three, the chain must read this state to enforce the rule, so +the state is public by construction. See \[[patterns/squads-permission-model]\] +and the Safe contract architecture note \[[tools/safe-smart-account]\]. + +Bitcoin native script (P2SH / P2WSH) reveals the full script (all public keys +and the threshold) at spend time. Taproot changes this: a key-path spend using +MuSig2 reveals nothing (see section 3), while a script-path spend reveals only +the executed leaf and hides sibling leaves via the Merkle tree +(\[[patterns/taproot-key-path-musig2]\]). + +FROST is the outlier: the threshold is enforced cryptographically off-chain, and +the chain sees a single Schnorr signature. Signer count, threshold, and the fact +that the account is a multisig at all are invisible +(\[[patterns/privacy-landscape]\]). + +### 1.2 Approval attribution and pending proposals (items 4-5) + +Squads persists each approval as separate on-chain state before execution, which +produces a live, queryable pending-proposal view: any observer can see who has +approved and who has not, in real time +(\[[patterns/squads-transaction-lifecycle]\]). Safe typically collects +signatures off-chain and presents them together in the final `execTransaction` +call; owners may optionally record consent early with the on-chain `approveHash` +function. + +It is worth stating precisely what this difference is and is not. Both models +yield an on-chain, verifiable record of who authorised an action *after it +executes*: Safe carries the signatures in the executing transaction, and Squads +carries them in the proposal account. Neither model has a public authorisation +audit trail that the other lacks. The genuine difference is only *staging*: +Squads makes approvals public before execution as a live pending view; Safe does +not. This is a coordination-visibility difference, not an audit-trail advantage +of one over the other. + +A separate and distinct property, noted in the Bybit analysis +(\[[patterns/security-incidents-safe]\]), is *intent verifiability at signing +time*: with off-chain signature collection there is no on-chain record that a +signer intended the transaction they actually signed, which is the gap both the +Bybit (February 2025, ~US$1.5B) and WazirX (July 2024, ~US$235M) incidents +exploited at the UI layer. This is about what a signer can verify at the moment +of signing, not about what survives on-chain afterwards. + +### 1.3 Action, holdings, execution linkage (items 6-8) + +On every researched account-model multisig, the executed action and its effects +are public: the transaction, its target, its calldata, and the resulting balance +changes are all on-chain. The multisig's vault balance is likewise public +contract or PDA state. On Bitcoin, amounts and outputs are public per-UTXO and +pseudonymous; the spending input links the effect back to the multisig UTXO. + +No researched implementation hides the link between a multisig and the on-chain +effects it produces. Where privacy exists (FROST, Taproot key-path), it hides +the *multisig structure*, not the *transaction effect*: the payment itself is +still a visible Bitcoin transaction, just one that looks single-signer. + +### 1.4 Coordination content and social graph (items 9-10) + +Coordination content is off-chain in every ecosystem, because signing protocols +define message formats but not transports (see section 4). What differs is what +the transport leaks. Bitcoin coordinators (Sparrow, Specter) exchange partially +signed transactions over a channel the user chooses (SD card, QR, USB, file +share) and add no transport of their own +(\[[patterns/inband-signing-coordination]\]). Safe's self-hosted transaction +service is a purpose-built relay; whoever operates it sees pending transaction +hashes, collected signatures, and which owners have approved +(\[[patterns/off-chain-signature-relay]\], +\[[patterns/safe-service-architecture]\]). + +The co-signing social graph (that a particular set of accounts jointly +administers one multisig) is not treated as a distinct privacy concern by any +researched implementation. On account-model chains it falls directly out of the +public signer set; on Bitcoin it is inferable at spend. No surveyed tool offers +a metadata-resistant coordination channel. + +## 2. The LEE execution model (public vs private accounts) + +This section records how the Logos Execution Environment handles state, because +it is what makes every "yes" in the section 1 table possible. It is a +description of the platform, not a proposed design. + +Source: Logos documentation, "Introduction to the Logos Execution Zone" +(https://docs.logos.co/lez), accessed 2026-07-07. + +The LEE separates persistent state into two kinds of account, and runs the +**same program bytecode** over either: + +- **Public accounts** are stored on-chain as a map from account ID to state. The + account ID is publicly visible. Executions that modify public accounts are + validated by LEZ validators through transparent re-execution, like a standard + RISC-V call. + +- **Private accounts** are stored locally on the account holder's own node. When + their state changes, only a **commitment** to the new post-state is published + on-chain, together with a **nullifier** that retires the previous commitment + so it cannot be reused. Correctness is proven with a Risc0 zero-knowledge + proof that validators verify without seeing the underlying data. Each private + account carries a nullifier keypair (the private key authorises executions; + the public key serves as the account ID) and a viewing keypair (used to + produce and verify proofs without revealing the owner). + +The product consequence for multisig is direct: running a multisig program over +private accounts means the chain records only a post-state commitment, a +nullifier, and a validity proof. It does not record the members, the threshold, +the approvals, the pending proposal, or the action. Privacy on LEZ is therefore +not a feature that must be added to a multisig; it is the native +private-execution mode of the platform applied to the multisig's accounts. This +is what distinguishes LEZ from every account-model chain in this survey, where +the chain must read the quorum state in the clear in order to enforce it. + +## 3. Quorum privacy across ecosystems + +The degree to which a multisig's structure is visible follows directly from +where the quorum is enforced. The pattern is consistent across every +implementation studied (\[[patterns/privacy-landscape]\]): + +| Posture | How achieved | What remains visible | +| ---------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------- | +| Full structural privacy (FROST; MuSig2 n-of-n) | Quorum enforced off-chain in a cryptographic session; one Schnorr signature on-chain | Nothing about the multisig; looks single-key | +| Partial (Taproot script-path, via MAST) | Unused script leaves hidden in a Merkle tree | The executed quorum leaf (its keys and threshold) | +| None (P2WSH; Safe; Squads; ERC-4337) | Quorum enforced by reading on-chain state | Members, threshold, and every approval | + +Two observations hold across the whole survey: + +1. Every implementation that achieves on-chain structural privacy does so by + moving multisig logic *off-chain* into a cryptographic session. Every + implementation that keeps multisig logic *on-chain* is transparent by + construction, because the chain must read the quorum to enforce it. + +2. MuSig2 achieves this only for n-of-n (all signers must participate). Genuine + k-of-n structural privacy on Bitcoin requires FROST, which as of 2026-07-06 + is still at BIP-draft stage and supported only by purpose-built hardware + (Frostsnap's ESP32-C3 device); no mainstream hardware wallet supports it + (\[[patterns/frost-taproot-privacy]\], \[[tools/bitcoin-frost-threshold]\]). + +The centralised industry "solution" to account-model privacy (a trusted relayer +or co-processor that manages signer identity off-chain and presents a single +abstract signer on-chain) trades sovereignty for privacy. Community proposals +for private Safe ownership (zkSafe, Semaphore-based anonymous signer modules) +exist but none reached production sovereign tooling; they required either a +trusted setup or a centralised coordinator (\[[patterns/privacy-landscape]\]). + +## 4. Coordination: how signers reach quorum + +Signing coordination is either **in-band** (the signing-round messages flow +through the same protocol or network as the final transaction) or +**out-of-band** (signers exchange signing material through a medium external to +the protocol). The split follows the execution model +(\[[patterns/inband-signing-coordination]\]): + +| Implementation | Coordination mode | Channel | +| ---------------------------- | ----------------- | ------------------------------------------------------------------------------------------------- | +| Squads v4 | In-band | Solana chain: proposals and per-member approvals are native instructions | +| Safe via `approveHash` | In-band | EVM chain: each owner records approval on-chain | +| Safe via transaction service | Relay-mediated | A purpose-built HTTP relay, part of the Safe stack but not the chain | +| ERC-4337 (ZeroDev Kernel) | Out-of-band | Guardian signatures aggregated off-chain before submission to a bundler | +| FROST (Frostsnap) | In-band (session) | The coordinator app's own wire protocol carries DKG and signing rounds; no external file exchange | +| Sparrow, Specter | Out-of-band | Partially-signed transactions exchanged via SD card, QR, USB, or file share | + +Three facts about coordination bear on a product decision: + +- **Bitcoin's PSBT (BIP-174/370) is a container format, not a transport.** It + defines how to package a partially-signed transaction but specifies no way to + deliver it between signers. Sparrow and Specter document several transfer + methods precisely because none is built in + (\[[patterns/psbt-coordinator-pattern]\]). + +- **Account-model chains can coordinate in-band by storing coordination state + on-chain,** as Squads does with proposal and approval accounts. Safe's + on-chain `approveHash` does the same but is rarely used because paying gas per + signer per proposal is a deterrent; off-chain collection via the relay is the + common path. + +- **Threshold-signature schemes carry their own session protocol.** FROST's DKG + and signing rounds are a structured message exchange that runs within the + protocol; a coordinator app (or a peer-to-peer layer) implements it without + any external messaging service (\[[patterns/frost-usb-coordination]\], + \[[patterns/frost-dkg-ceremony]\]). Frostsnap deliberately runs this over USB + serial rather than airgapped QR, because a k-of-n session over QR codes needs + many scans per transaction and the usability cost drives users to skip + verification. + +The product gap this exposes: no surveyed sovereign multisig provides an +encrypted, metadata-resistant coordination channel. Coordination is either +public on-chain state (Squads), a relay that sees the metadata (Safe), or a +user-supplied external channel with no privacy guarantee (Bitcoin). An +end-to-end-encrypted messaging channel dedicated to a multisig's signers, such +as the Logos chat module, is not matched by any implementation in this survey. + +## 5. Roles, policies, and extensibility + +Beyond the basic M-of-N check, the surveyed implementations offer graduated +controls that shape what an operational multisig can express. + +- **Role separation.** Squads assigns each signer a three-bit permission mask + (Initiate / Vote / Execute), so a proposing key need not be a voting key, and + execution can be a separate role. Program invariants require at least one + signer with each permission and forbid an impossible threshold + (\[[patterns/squads-permission-model]\]). ZeroDev Kernel expresses roles as + weighted guardians, where the threshold is a minimum cumulative weight + (\[[patterns/weighted-multisig-onchain-vote]\]). + +- **Time locks and cancellation.** Squads supports a per-multisig time lock (0 + to about three months) enforced on-chain between approval and execution, and + allows an approved proposal to be cancelled by a threshold of cancellation + votes before it executes (\[[patterns/squads-transaction-lifecycle]\]). Safe's + core contract has no time lock; it must be added as a guard or module + (\[[tools/safe-smart-account]\]). + +- **Spending limits and policies.** Squads supports policy accounts with their + own signer set and threshold for specific action types, and spending-limit + authorities (\[[patterns/squads-policy-framework]\]). Safe offers an Allowance + Module for spending limits. + +- **Extensibility, and its cost.** Safe's guard and module system lets arbitrary + contracts hook execution (guards) or execute without the M-of-N check + (modules) (\[[patterns/guard-module-system]\]). This is powerful and + dangerous: a module has unlimited authority, and the SquidRouter incident (May + 2026, ~US$3.2M) drained 86 Safes through a vulnerable third-party module that + owners had enabled (\[[patterns/security-incidents-safe]\]). ERC-4337 uses a + modular validator-plugin model with a defined install/uninstall lifecycle + (\[[patterns/erc7579-module-lifecycle]\], + \[[patterns/modular-validator-plugin]\]). + +## 6. Composition: how a multisig triggers actions + +A multisig is only useful if it can act on other programs. The surveyed +implementations delegate execution rather than embedding target logic: + +- **Safe** executes an arbitrary `to` / `value` / `data` call (or delegatecall) + through `execTransaction`, and batches multiple sub-calls through the + MultiSend library (\[[tools/safe-smart-account]\]). + +- **Squads** executes a stored instruction against a target program through a + vault cross-program invocation, and supports batches executed sequentially + after a single approval (\[[patterns/squads-transaction-lifecycle]\]). + +- **The Logos public multisig sample app** (`logos-co/lez-multisig`) follows the + Squads model on LEZ: a proposal stores a serialised instruction and target + program ID, and on execution the multisig emits a LEZ `ChainedCall` to the + target, so the multisig never modifies external state directly and composes + with any LEZ program. Source: `logos-co/lez-multisig` README and SPEC, + accessed 2026-07-07. Its accounts (multisig state, proposal, vault) are public + LEZ accounts; per the section 1 table, the same design run over private + accounts would publish only commitments. + +The composition mechanism is orthogonal to privacy: whether the multisig's own +state is public or private, it still delegates to a target program, and the +target execution's own visibility follows that target's account choices. + +## 7. Hardware signing and sovereignty (operational notes) + +Two operational facts recur across the survey and bear on any real deployment: + +- **Hardware-wallet support is uneven.** Bitcoin has the broadest coverage: PSBT + and the hardware wallet interface (HWI) support Coldcard, Trezor, Ledger, + Jade, BitBox02, and many airgapped signers + (\[[patterns/airgapped-signing-pattern]\]). EVM signing uses EIP-712 typed + data on Ledger, Trezor, and Keystone. Solana hardware signing requires + blind-signing in practice. FROST supports only Frostsnap's purpose-built + device, no mainstream hardware wallet. + +- **Sovereignty has different costs per stack.** Bitcoin coordinators need a + Bitcoin Core or Electrum backend. Safe can run as a full Docker stack (many + services) or CLI-only with no infrastructure. Squads needs only an RPC node. + ERC-4337 requires a bundler, which must be separately self-hosted or is + defaulted to a hosted provider (\[[patterns/bundler-liveness-dependency]\], + \[[patterns/server-first-coordinator-pattern]\]). + +## 8. Summary of observations + +- A multisig involves at least ten distinct data and metadata items (section 1); + on every account-model chain surveyed, most of them are public by construction + because the chain must read the quorum to enforce it. + +- The only implementations that keep multisig structure private (FROST, MuSig2 + n-of-n) do so by moving the quorum off-chain into a cryptographic session, at + the cost of hardware and tooling immaturity and, for MuSig2, an n-of-n-only + limitation. + +- The LEE private-account model is the one execution environment in this survey + where a fully programmable M-of-N multisig can run with its state (members, + threshold, approvals, action) published only as commitments, without a trusted + coordinator and without abandoning k-of-n. + +- "On-chain versus off-chain approval" is a coordination-visibility choice, not + an audit-trail trade-off: both models yield an on-chain authorisation record + at execution. + +- No surveyed sovereign multisig offers an encrypted, metadata-resistant + coordination channel for its signers. + +## References + +| Source | URL | Access date | +| ---------------------------------------- | ------------------------------------------------------------------------------------ | ----------- | +| research-multisig-sovereign vault | https://github.com/marclawclaw/research-multisig-sovereign | 2026-07-06 | +| Introduction to the Logos Execution Zone | https://docs.logos.co/lez | 2026-07-07 | +| Squads smart-account-program | https://github.com/Squads-Protocol/smart-account-program | 2026-07-06 | +| Safe smart account | https://github.com/safe-global/safe-smart-account | 2026-07-06 | +| Frostsnap | https://github.com/frostsnap/frostsnap | 2026-07-06 | +| ZeroDev Kernel | https://github.com/zerodevapp/kernel | 2026-07-06 | +| Sparrow Wallet | https://github.com/sparrowwallet/sparrow | 2026-07-06 | +| Specter Desktop | https://github.com/cryptoadvance/specter-desktop | 2026-07-06 | +| rust-bitcoin | https://github.com/rust-bitcoin/rust-bitcoin | 2026-07-06 | +| BIP-327 (MuSig2) | https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki | 2026-07-06 | +| BIP-341 (Taproot) | https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki | 2026-07-06 | +| Bybit incident analysis (Check Point) | https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/ | 2026-07-06 | +| WazirX hack analysis (QuillAudits) | https://www.quillaudits.com/blog/hack-analysis/wazirx-235m-hack | 2026-07-06 | +| logos-co/lez-multisig | https://github.com/logos-co/lez-multisig | 2026-07-07 | From 2f12e46740f632581f5413e5121c55d3af694781 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 3 Aug 2026 12:16:39 +1000 Subject: [PATCH 02/14] RFP-005: address PR #113 review - Fresh code and architecture: drop 'hardens the sample app' framing; the PoC stays as prior art in Resources only - Add value-in-custody figures (Safe US$60B+, Squads US$15B+, 2026-08-03) - Remove unassigned references (A-multisig, LD-private-dao, SA-public-multisig, RD-chat); keep LP-0002 only - Execution requirement specifies the what: run any arbitrary program in the given LEZ - RFP is self-contained: no references to the appendix - Settle decisions: private-by-default with auditability/transparency options (public posture, view-key selective disclosure, zk proof-of-holding soft req); approvals flow through the E2EE room - Revisit quorum-model decision per LEZ shared-private-account (GMS) properties: N-of-N key semantics, no revocation, program/PDA vs group-account vs threshold-crypto vault options - Appendix: cite original sources instead of the research vault; add custody figures, LEZ shared-private-account properties and treasury auditability configurations --- RFPs/RFP-005-multisig-and-coordination.md | 476 ++++++++++---------- appendix/multisig-coordination-ecosystem.md | 272 ++++++++--- 2 files changed, 447 insertions(+), 301 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 3b075c93..8fb2e9a6 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -6,11 +6,9 @@ funding: $XXXXX status: open dependencies: - id: LP-0002 - reason: Private M-of-N multisig sample-app proof; establishes the private-account multisig design this RFP hardens to production. - - id: SA-public-multisig - reason: The public multisig sample app (logos-co/lez-multisig) is the transparent baseline whose proposal→approve→execute→ChainedCall design this RFP builds on. - - id: RD-chat - reason: The Logos chat module provides the end-to-end-encrypted, metadata-resistant coordination channel required per multisig for signer deliberation and, optionally, signing-material transport. + reason: LP-0002 demonstrates an M-of-N multisig running over LEE private + accounts; this RFP's private-by-default posture relies on that execution + model being production-available on LEZ. category: Applications & Integrations --- @@ -19,25 +17,25 @@ category: Applications & Integrations ## 🧭 Overview Build a production-ready M-of-N multisig program on the Logos Execution Zone -(LEZ), together with an in-band coordination channel so signers can deliberate -and reach quorum without leaving the application. A multisig is the execution -layer for shared custody, treasuries, and DAOs: the Logos launch-day Private -Multisig app and the Private DAO both depend on it. A public multisig sample app -already exists on LEZ (`logos-co/lez-multisig`, inspired by Squads Protocol v4): -proposals live on-chain, signers approve asynchronously, and execution delegates -to any LEZ program via `ChainedCall`. This RFP hardens that prototype into a -production program and adds the properties LEZ makes uniquely possible: multisig -state that can be kept private, and a coordination channel that is encrypted and -metadata-resistant. - -Multisig is the single most widely used custody primitive in the ecosystem. On -Ethereum, Safe (formerly Gnosis Safe) is the dominant standard, deployed across -86 networks; on Solana, Squads is the analogue. Both are fully transparent by -construction: members, threshold, every approval, and every action are public -on-chain state, because the chain must read the quorum in order to enforce it. -That transparency has been an attack surface: the Bybit (February 2025, -~US$1.5B) and WazirX (July 2024, ~US$235M) incidents both targeted fully visible -Safe configurations at the signing layer. +(LEZ), together with an in-band coordination channel so signers can propose, +deliberate, collect approvals, and reach quorum without leaving the +application. A multisig is the execution layer for shared custody, treasuries, +and DAOs: the Logos launch-day Private Multisig app and the Private DAO both +depend on it. The program is designed and implemented from scratch for LEZ, +taking as its baseline the properties LEZ makes uniquely possible: multisig +state that is private by default, and a coordination channel that is encrypted +and metadata-resistant. + +Multisig is the single most widely used custody primitive in the ecosystem, and +the value in multisig custody today is immense. Safe (formerly Gnosis Safe), +the dominant standard on Ethereum, is deployed across 86 networks and +self-reports over US$60B in assets secured; Squads, the Solana analogue, +self-reports over US$15B (protocol-reported figures, 2026-08-03). Both are +fully transparent by construction: members, threshold, every approval, and +every action are public on-chain state, because the chain must read the quorum +in order to enforce it. That transparency has been an attack surface: the +Bybit (February 2025, ~US$1.5B) and WazirX (July 2024, ~US$235M) incidents +both targeted fully visible Safe configurations at the signing layer. The team building this should have deep experience in multisig or threshold custody design, Rust program development for a RISC-V or zkVM target, and @@ -48,17 +46,17 @@ applied cryptography. Shared custody is a precondition for organisations to operate on Logos. Without a production multisig, there is no treasury, no DAO execution layer, and no shared control of protocol admin authorities. The launch-day Private Multisig -app (`A-multisig`) and the Private DAO (`LD-private-dao`) are blocked on it. - -LEZ also makes it possible to close a gap no sovereign multisig has closed. As -the [appendix](../appendix/multisig-coordination-ecosystem.md) documents, every -existing implementation that keeps multisig structure private (FROST, MuSig2 -n-of-n) does so by moving the quorum off-chain into a cryptographic session, at -the cost of hardware immaturity and, for MuSig2, an n-of-n-only limitation. -Every implementation that keeps the quorum on-chain is transparent. On LEZ, the -same multisig program can run over private accounts, so the chain records only a -commitment to the post-state and a validity proof, without a trusted coordinator -and without giving up k-of-n. This RFP is the vehicle for delivering that. +app and the Private DAO are blocked on it. + +LEZ also makes it possible to close a gap no sovereign multisig has closed. +Every existing implementation that keeps multisig structure private (FROST, +MuSig2 n-of-n) does so by moving the quorum off-chain into a cryptographic +session, at the cost of hardware immaturity and, for MuSig2, an n-of-n-only +limitation. Every implementation that keeps the quorum on-chain is transparent. +On LEZ, the same multisig program can run over private accounts, so the chain +records only a commitment to the post-state and a validity proof, without a +trusted coordinator and without giving up k-of-n. This RFP is the vehicle for +delivering that. ## ✅ Scope of Work @@ -70,41 +68,40 @@ and without giving up k-of-n. This RFP is the vehicle for delivering that. members and a threshold M; an action requires at least M approvals before it can execute. Members, threshold, and the action set are configurable at creation. -2. Support the full proposal lifecycle: a member proposes an action; members - approve or reject asynchronously; once M approvals are collected the action - becomes executable; if rejections make M approvals impossible the proposal is - dead. Support proposal cancellation before execution and proposal expiry. -3. Execute approved actions by delegating to any LEZ program via `ChainedCall`, - following the existing `logos-co/lez-multisig` design: the proposal stores a - serialised instruction and target program ID, and execution delivers it to - the target. The multisig never modifies external state directly. See - [Appendix section 6](../appendix/multisig-coordination-ecosystem.md#6-composition-how-a-multisig-triggers-actions). +2. Support the full proposal lifecycle. Proposals and approvals are coordinated + off-chain through the per-multisig coordination room (requirement F.8): a + member publishes a proposal to the room; members approve or reject + asynchronously; once M approvals are collected the action can be executed, + and the program verifies the collected approvals at execution. Proposals + carry an expiry after which the program rejects execution. +3. Execute approved actions on any arbitrary program deployed in the given LEZ: + a proposal designates a target program and an instruction, and on execution + the multisig program invokes the target on the multisig's authority. The + multisig never modifies another program's state directly. The design must + not special-case any particular target program. 4. Support configuration changes (add or remove a member, change the threshold) through the same M-of-N approval flow, so structural changes cannot bypass the quorum. 5. Support role separation among members so that the ability to propose, to - approve, and to execute can be assigned independently, following the Squads - permission model documented in - [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). - At minimum, a proposing key need not be an approving key. + approve, and to execute can be assigned independently. At minimum, a + proposing key need not be an approving key. 6. Support an optional per-multisig time lock: a configurable delay between an action reaching quorum and becoming executable, enforced by the program. A time lock of zero means immediate execution. 7. Support an optional spending-limit policy: a member (or sub-quorum) may - execute transfers up to a configured limit without the full M-of-N approval, - per the policy model in - [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). + execute transfers up to a configured limit without the full M-of-N approval. 8. Provision an end-to-end-encrypted coordination room per multisig using the - Logos chat module (RD-chat), scoped to the multisig's members, for signer - deliberation. See the Coordination Architecture section for what this channel - carries and its privacy properties. -9. Support the privacy posture selected under Decision 1 (see Decisions for - Review). The program must run the multisig over the account kind(s) required - by that posture (public accounts, private accounts, or both) so that the data - items designated private in Decision 1 are not published on-chain. See - [Appendix section 1](../appendix/multisig-coordination-ecosystem.md#1-what-data-a-multisig-involves-and-whether-it-can-be-private) - and - [section 2](../appendix/multisig-coordination-ecosystem.md#2-the-lee-execution-model-public-vs-private-accounts). + Logos chat module, scoped to the multisig's members. The room carries both + human deliberation and machine coordination: proposals are published to the + room, member approvals are collected through it, and the resulting approval + package is presented to the program at execution. See the Coordination + Architecture section. +9. Run the multisig private by default: the program runs over LEE private + accounts so that the multisig data items listed in the Privacy Architecture + section are not published on-chain. Support the auditability and + transparency options defined there: an operator-selectable fully public + posture, and selective disclosure of a private multisig's state to a chosen + audience via view keys. #### Usability @@ -120,36 +117,40 @@ and without giving up k-of-n. This RFP is the vehicle for delivering that. 4. Provide an IDL for the LEZ program, preferably using the [SPEL framework](https://github.com/logos-co/spel). 5. Documentation must clearly explain, for each action, what information is - public and what is private under the selected privacy posture (which data - items from Appendix section 1 are published on-chain and which are not), so a - multisig operator understands exactly what an observer can see. + public and what is private under the multisig's configured posture (which of + the data items enumerated in the Privacy Architecture section are published + on-chain and which are not), so a multisig operator understands exactly what + an observer can see, including what becomes visible to an audience once a + view key is shared with it. 6. Before a member signs an approval, the mini-app must display the exact action that approval authorises (target program, decoded instruction, amounts), so the member verifies what they are signing rather than a UI-rendered summary. - This directly addresses the signing-layer attack surface described in - [Appendix section 1.2](../appendix/multisig-coordination-ecosystem.md#12-approval-attribution-and-pending-proposals-items-4-5). + This is the primary mitigation for the signing-layer attack surface behind + the Bybit and WazirX losses: in both incidents, signers authorised what a + compromised UI showed them, not what was actually executed. 7. Failed or rejected proposals and executions must return clear, actionable error messages. #### Reliability -1. Multisig state must remain consistent under concurrent approvals from - different members; no approval is lost or double-counted, and an action - cannot execute with fewer than M valid approvals. -2. A configuration change (member set or threshold) must invalidate in-flight - proposals whose approval set was gathered under the old configuration, unless - they had already reached quorum, following the stale-proposal handling in - [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). +1. The program must verify, at execution, that the presented approvals are M + distinct valid approvals from current members on exactly the action being + executed; no approval is double-counted or replayed across proposals, and an + action cannot execute with fewer than M valid approvals. +2. A configuration change (member set or threshold) must invalidate approval + sets gathered under the old configuration: an approval collected before the + change must not count toward quorum after it, unless the action had already + reached quorum and been scheduled for execution. #### Performance -1. Each operation (create, propose, approve, reject, execute) completes within a - single LEZ transaction. -2. Compute unit usage and transaction size of each operation must be documented - and benchmarked against LEZ devnet limits. If the selected privacy posture - uses private-account execution, the per-proof cost and the per-block private - transaction throughput must be measured and reported, since they bound how - many approvals can be processed per block. +1. Each on-chain operation (create, execute, configuration change) completes + within a single LEZ transaction. Proposal publication and approval + collection happen in the coordination room, not on-chain. +2. Compute unit usage and transaction size of each on-chain operation must be + documented and benchmarked against LEZ devnet limits. Because execution runs + in the private path by default, the per-proof cost and the per-block private + transaction throughput must be measured and reported. #### Supportability @@ -181,60 +182,99 @@ If possible. #### Functionality 1. Support batch proposals: a single proposal covering multiple actions that are - approved once and executed atomically or in sequence, per the Squads batch - model in - [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). + approved once and executed atomically or in sequence. 2. Support weighted approvals, where members carry numeric weights and the - threshold is a minimum cumulative weight, per - [Appendix section 5](../appendix/multisig-coordination-ecosystem.md#5-roles-policies-and-extensibility). + threshold is a minimum cumulative weight. +3. Support zero-knowledge proof-of-holding: the multisig can prove its vault + holds at least a stated amount, verified against the on-chain commitment, + without revealing the exact balance (see the auditability options in Privacy + Architecture). ### Out of Scope The following are explicitly excluded from this RFP: - A FROST or MuSig2 threshold-signature implementation. Structural privacy on - LEZ is achieved through private-account execution (Appendix section 2), not - through an off-chain threshold-signature session. Threshold-signature schemes - are documented in the appendix as ecosystem context only. + LEZ comes from running the multisig program over private accounts, not from + an off-chain threshold-signature session. A threshold scheme layered over + shared-account keys remains a documented future extension (see the Decision + for Review), but no threshold-signature implementation is delivered here. - Recovery of a multisig whose members have lost quorum-many keys. Social or time-locked key recovery is a separate concern and is not required here. ### Coordination Architecture Every multisig provisions one end-to-end-encrypted room using the Logos chat -module (RD-chat), scoped to its members. As the -[appendix](../appendix/multisig-coordination-ecosystem.md#4-coordination-how-signers-reach-quorum) -documents, no surveyed sovereign multisig offers an encrypted, -metadata-resistant coordination channel: coordination today is either public -on-chain state (Squads), a relay that sees the metadata (Safe), or a -user-supplied external channel (Bitcoin). The Logos chat module closes that gap. - -What the room carries, and whether machine coordination (proposals and -approvals) also flows through it or stays as on-chain state, is the subject of -Decision 2 (see Decisions for Review). In all variants the room carries human -deliberation: the discussion among signers about whether to approve. The room is -coordination, not enforcement: quorum is always enforced by the program -on-chain, never by the chat channel. +module, scoped to its members. The room is the single channel for both kinds of +coordination traffic: + +- **Human deliberation**: the discussion among signers about whether to + approve. +- **Machine coordination**: proposals are published to the room, and members' + approvals (signatures over the proposal) are collected through it. Once M + approvals are gathered, the approval package is submitted for execution; the + program verifies the collected approvals at execution time. + +No sovereign multisig in production today offers an encrypted, +metadata-resistant coordination channel: coordination is either public on-chain +state (Squads), a relay that sees the metadata (Safe), or a user-supplied +external channel (Bitcoin). The Logos chat module closes that gap. Carrying +approvals through the room removes per-approval on-chain writes and keeps +pending-proposal metadata off-chain even for a public-posture multisig. An +on-chain proposal record is not an audit-trail advantage over this model: both +models yield a verifiable record of who authorised an action at execution. + +The room is coordination, not enforcement: quorum is always verified and +enforced by the program at execution, never by the chat channel. Because there +is no live on-chain pending view, the client must reliably gather, retain, and +present room state so signers always see the current proposal set and collected +approvals. ### Privacy Architecture -A multisig involves at least ten distinct data and metadata items, enumerated in -[Appendix section 1](../appendix/multisig-coordination-ecosystem.md#1-what-data-a-multisig-involves-and-whether-it-can-be-private): -the existence of the multisig, the member set, the threshold, per-signer -approval attribution, pending-proposal metadata, the action payload, the vault -balance, execution linkage, coordination content, and the co-signing social -graph. On LEZ, each of these can independently be public or private, because the -Logos Execution Environment runs the same program over public accounts (visible +A multisig involves at least ten distinct data and metadata items: the +existence of the multisig, the member set, the threshold, per-signer approval +attribution, pending-proposal metadata, the action payload, the vault balance, +execution linkage, coordination content, and the co-signing social graph. On +LEZ, each of these can independently be public or private, because the Logos +Execution Environment runs the same program over public accounts (visible on-chain) or private accounts (only a post-state commitment and validity proof -on-chain), per -[Appendix section 2](../appendix/multisig-coordination-ecosystem.md#2-the-lee-execution-model-public-vs-private-accounts). - -Which of these items must be private, which are left to the operator's choice, -and which are private by default with a public opt-out, is the subject of -Decision 1 (see Decisions for Review). Where identity is concerned, the property -in question is unlinkability between a user's account and its role in a -multisig, not concealment of the user. Documentation (Usability requirement U.5) -must state the resulting public/private split explicitly for the chosen posture. +on-chain). + +**Posture: private by default.** Under this RFP the multisig runs over private +accounts by default, so none of the ten items is published in the clear; +coordination content is always private (the E2EE room), and the co-signing +social graph is not readable from chain state. Where identity is concerned, the +property in question is unlinkability between a user's account and its role in +a multisig, not concealment of the user. + +**Auditability and transparency options.** Privacy is not the opposite of +oversight, and different organisations need different audiences able to inspect +the multisig: a corporate or org multisig may need a limited auditor group, +while a DAO may need its entire membership to be able to audit. The program +must support: + +1. **Public posture (operator-selectable).** At creation the operator may + deploy the multisig fully public instead of private, for treasuries that + want anyone to be able to inspect configuration, holdings, and activity at + all times. +2. **Selective disclosure via view keys.** LEZ private accounts separate the + spending key from a viewing key that decrypts the account's on-chain state + without granting spending authority. Distributing the viewing key to a + defined audience (for example, to DAO members through the coordination room + or another member-restricted channel) lets that audience inspect the + multisig's holdings and configuration at any time, without making them + public and without granting spending power. A member holding the viewing key + can also demonstrate to a new joiner that the treasury holds what the key + holders claim, which serves as standing proof of holding. View-key + distribution is not currently exposed by the LEZ wallet, so the SDK must + implement it. A shared viewing key cannot be revoked: rotating the audience + requires migrating the multisig to a fresh account, and the documentation + must say so. + +Documentation (Usability requirement U.5) must state the resulting +public/private split explicitly for the configured posture, including who can +see what once a view key has been shared. ## ⚠ Platform Dependencies @@ -245,50 +285,60 @@ but a working on-chain deployment depends on the primitives below. #### Private-account execution (core LEE feature) -If the selected privacy posture (Decision 1) requires any multisig data to be -private, the program relies on LEE private accounts: post-state commitments, -nullifiers, and Risc0 validity proofs, as described in -[Appendix section 2](../appendix/multisig-coordination-ecosystem.md#2-the-lee-execution-model-public-vs-private-accounts). -These are core LEE features rather than lambda prizes; proposers should confirm -the current state of private-account support on LEZ devnet against the Resources -below before relying on it, including whether program-derived private accounts -are supported for the multisig's vault. +The private-by-default posture requires running the multisig over LEE private +accounts: post-state commitments, nullifiers, and Risc0 validity proofs. These +are core LEE features, demonstrated for an M-of-N multisig under LP-0002; +proposers should confirm the state of private-account support on LEZ devnet +against the Resources below before relying on it, including whether +program-derived private accounts are supported for the multisig's vault — that +property determines the options in the Decision for Review below. + +#### Shared private accounts (key separation and group keys) + +The auditability options rely on LEE key separation: a private account has a +spending (nullifier) key and a viewing key, and sharing the viewing key yields +a view-only auditor. LEZ also provides group-owned shared private accounts +derived from a single shared group secret, whose semantics matter for the vault +design: every member of the group derives full spending authority (there is no +view-only or threshold share of the group secret), group membership is not +recorded on-chain, and there is no revocation short of migrating funds to a new +account. Proposers should confirm these properties against the LEZ +documentation and codebase before relying on them. -#### Logos chat module (RD-chat) +#### Logos chat module The per-multisig coordination room (Functionality requirement F.8) depends on -the Logos chat module, tracked as `RD-chat`. Proposers should confirm the -module's availability and its SDK surface for creating a member-scoped, -end-to-end-encrypted room before relying on it. +the Logos chat module. Proposers should confirm the module's availability and +its SDK surface for creating a member-scoped, end-to-end-encrypted room before +relying on it. ### Resolved dependencies -#### Cross-program calls via ChainedCall +#### Cross-program execution -Execution delegates to a target program via `ChainedCall` (Functionality -requirement F.3). This is the mechanism the existing `logos-co/lez-multisig` -sample app already uses, delivered by the LEZ team as part of the core runtime. +Execution of an arbitrary LEZ program (Functionality requirement F.3) relies on +the LEZ runtime's cross-program execution support, which is delivered as part +of the core runtime. Proposers should confirm its mechanism and constraints on +devnet. ### Risks #### Private-transaction throughput -If the privacy posture uses private-account execution, each approval that -mutates private state produces a proof and consumes a private-transaction slot. -LEZ private-transaction throughput per block is limited (as of 2026-04, one -private transaction per block on the reference deployment); a multisig with many -members approving in quick succession may be bounded by this. Performance -requirement P.2 requires this to be measured and reported. If throughput is a -constraint, the proposal should describe how approvals are batched or -aggregated. +Running over private accounts, each on-chain operation produces a proof and +consumes a private-transaction slot. LEZ private-transaction throughput per +block is limited (as of 2026-04, one private transaction per block on the +reference deployment). Carrying approvals through the coordination room removes +per-approval on-chain writes, so the on-chain footprint stays small (creation, +executions, configuration changes), but it remains bounded by this throughput. +Performance requirement P.2 requires this to be measured and reported. #### Signing-layer trust -As the appendix records, the Bybit and WazirX losses were not smart-contract -failures; they exploited the gap between what a signer saw in a UI and what they -actually authorised. Usability requirement U.6 (show the exact decoded action -before signing) is the primary mitigation and must not be treated as optional -polish. +The Bybit and WazirX losses were not smart-contract failures; they exploited +the gap between what a signer saw in a UI and what they actually authorised. +Usability requirement U.6 (show the exact decoded action before signing) is the +primary mitigation and must not be treated as optional polish. ## 👤 Recommended Team Profile @@ -302,11 +352,11 @@ Team experienced with: ## ⏱ Timeline Expectations -Estimated duration: **12 weeks** (production-hardening of the proven -`lez-multisig` design, plus the coordination room and the selected privacy -posture). The estimate assumes the privacy posture is settled at contracting -time via Decision 1; a posture requiring private-account execution of the full -proposal lifecycle sits at the upper end of the range. +Estimated duration: **12 weeks** (fresh implementation of the M-of-N program +with its private-by-default execution path, the coordination room with in-room +approval collection, and the SDK, CLI, and mini-app). The privacy posture and +the coordination channel are settled (see below); the remaining open decision +affects the vault design and sits within this estimate. ## 🌍 Open Source Requirement @@ -315,92 +365,54 @@ All code must be released under the **MIT+Apache2.0 dual License**. ## Resources - [Logos Documentation](https://github.com/logos-co/logos-docs) -- [logos-co/lez-multisig](https://github.com/logos-co/lez-multisig): the - existing public multisig sample app this RFP hardens +- [logos-co/lez-multisig](https://github.com/logos-co/lez-multisig): a public + multisig proof-of-concept sample app on LEZ; prior art only — this RFP + commissions a fresh design and implementation - [Introduction to the Logos Execution Zone](https://docs.logos.co/lez): the public/private account model this RFP relies on ## 🧩 Decisions for Review -The following three decisions shape the deliverable and should be settled before -contracting. Each is presented as options A / B / C with the trade-offs drawn -from the [appendix](../appendix/multisig-coordination-ecosystem.md). A -recommended default is marked, but the choice is open. - -### Decision 1 — Privacy posture: which multisig data is private? - -Per Appendix section 1, a multisig involves ten distinct data items, each of -which can independently be public or private on LEZ. This decision sets, per -item, whether privacy is mandatory, operator-selectable, or default-on. - -- **Option A — Public multisig (transparent, like Safe/Squads).** All ten data - items are public. Simplest to build and audit; matches the existing - `lez-multisig` sample app; gives the transparent, publicly-inspectable - behaviour some treasuries and DAOs want. But it carries the same - transparency-as-attack- surface profile as Safe and Squads, and delivers none - of the LEZ privacy advantage. -- **Option B — Operator choice per multisig (recommended default).** The program - supports both public and private execution; at creation the operator chooses - the posture. A recommended default configuration is shipped (see below). - Maximises fitness across use cases (a transparent DAO treasury and a private - company multisig from the same program) at the cost of building and testing - both execution paths. Recommended default within this option: existence, - member set, approval attribution, action, execution linkage, and social graph - **private**; coordination content **always private** (E2EE room); threshold, - pending-proposal visibility, and holdings **operator-selectable**. -- **Option C — Private-by-default multisig.** All items that can be private are - private by default, with a per-item public opt-out. Leans hardest into the LEZ - differentiator and gives the strongest default privacy, but every deployment - pays the private-execution cost (proof generation, throughput limits per - Appendix section 2 and the Risk above) even where an operator did not need it. - -### Decision 2 — Coordination channel: where do approvals flow? - -Per Appendix sections 1.2 and 4, machine coordination (proposals and approvals) -can live as on-chain state or off-chain, while human deliberation is always -off-chain. This decision sets where each flows. In all options, quorum is -enforced on-chain by the program. - -- **Option A — On-chain approvals + E2EE deliberation room (recommended - default).** Proposals and approvals are program state on-chain (public, or - private per Decision 1); the E2EE room carries human deliberation only. Keeps - a clean, program-enforced approval record and a live pending view, exactly as - `lez-multisig` does today, while adding the encrypted discussion channel no - competitor offers. Note (per Appendix section 1.2) this on-chain record is not - an audit-trail advantage over off-chain collection; both yield a record at - execution. Its value here is a simple, verifiable machine channel. -- **Option B — Approvals carried through the E2EE room.** The room is both the - deliberation channel and the transport for signing material; the program - verifies the collected approvals at execution (the Safe off-chain-collection - shape, but over an encrypted, metadata-resistant channel). Removes - per-approval on-chain writes and hides pending-proposal metadata even in a - public posture, at the cost of a more complex client that must reliably gather - and present approvals, and no live on-chain pending view. -- **Option C — Both, operator-selectable.** Ship both channels and let the - operator choose per multisig. Most flexible; largest client surface to build - and test. - -### Decision 3 — Quorum model baseline - -Per Appendix sections 2 and 3, structural privacy on LEZ comes from -private-account execution of an account-model multisig, not from a -threshold-signature scheme. This decision confirms the baseline the program is -built on. - -- **Option A — Account-model quorum on LEZ, hardening `lez-multisig` - (recommended default).** Members and threshold are program state; approvals - are program-verified; privacy (if selected) comes from running over private - accounts. Direct continuation of the proven sample app; the appendix shows - this is the only surveyed path to private, coordinator-free, k-of-n multisig. -- **Option B — Threshold signatures (FROST-style), single aggregate signature - on-chain.** Maximal structural privacy at the signature layer, but the - appendix documents FROST as BIP-draft, hardware-immature, and (for MuSig2) - n-of-n only; this is why it is Out of Scope above. Listed for completeness; - not recommended. -- **Option C — Deliver the account model now, keep a threshold-signature variant - as a documented future extension.** Build Option A, and specify the interface - seam where a threshold-signature signing path could be added later without - redesign. +Two decisions that shaped earlier drafts are now settled and embedded in the +requirements above: the privacy posture is **private by default**, with the +auditability and transparency options listed in Privacy Architecture; and +**approvals flow through the E2EE coordination room**, with the program +verifying the collected approvals at execution (no per-approval on-chain +writes). One decision remains open. + +### Decision — M-of-N enforcement for the private vault + +A private multisig needs somewhere to hold value and somewhere to enforce the +quorum, and LEZ's shared-private-account mechanism constrains both. What is +known today: a LEZ private account can be shared through a single group secret +from which every member derives full spending and viewing authority — +effectively N-of-N, not M-of-N; the chain cannot distinguish a group-owned +account from a single-owner one; and there is no revocation short of migrating +funds to a fresh account. A genuine M-of-N must therefore be enforced somewhere +other than the group secret itself. + +- **Option A — Program-enforced M-of-N over a program-derived private + account.** The vault is a private account controlled by the multisig program; + the M-of-N check runs inside the program's verified execution, and members + hold no independent spending authority over the vault. The group-secret + mechanism is not used for spending. Strongest enforcement, and member changes + are program state changes rather than key migrations; depends on + program-derived private accounts being supported on LEZ. +- **Option B — Group-shared account as vault, M-of-N enforced in the approval + layer.** The vault is a group-shared private account and the multisig gates + which spends are authorised through its approval flow. Simpler account and + key-distribution story, but every group member cryptographically retains full + spending authority, so enforcement is procedural rather than cryptographic, + and excluding a member requires migrating the vault. +- **Option C — Group-shared account as vault, with threshold cryptography over + the group-derived keys** (for example a FROST-style scheme), giving + cryptographic M-of-N at the key layer. Strongest key-layer enforcement, but + immature tooling; threshold-signature implementation is out of scope for this + RFP, so this would be a documented future extension rather than a + deliverable. + +The proposer should state which baseline their design assumes; the choice will +be settled at contracting time. ## ✏️ How to Apply diff --git a/appendix/multisig-coordination-ecosystem.md b/appendix/multisig-coordination-ecosystem.md index 4d84e14c..7cdd675c 100644 --- a/appendix/multisig-coordination-ecosystem.md +++ b/appendix/multisig-coordination-ecosystem.md @@ -7,10 +7,9 @@ to the outside world?** It is written from a product angle (what an operator, a counterparty, or a passive observer can and cannot see), not a contract-internals angle. -All data is sourced from the -[research-multisig-sovereign](https://github.com/marclawclaw/research-multisig-sovereign) -vault; individual subject and pattern notes contain full citations. Access date -for all figures is 2026-07-06 unless otherwise noted. +Facts and figures are cited inline to their original sources, which are also +listed with access dates in the References section. Access date for all figures +is 2026-07-06 unless otherwise noted. This appendix contains facts and observations only. It does not state requirements, and it does not decide which data *should* be private for a Logos @@ -20,10 +19,23 @@ multisig: that is the subject of ## Protocols considered Nine implementations were studied, spanning the on-chain program layer and the -coordinator/UI layer across three ecosystems. Adoption is measured by GitHub -stars: multisig software holds assets in custody accounts rather than a DeFi -liquidity pool, so total-value-locked (TVL) is not an applicable metric, and no -authoritative TVL figure is published for the custody layer. +coordinator/UI layer across three ecosystems. Software-layer adoption is +measured by GitHub stars. For the custody layer the applicable adoption figure +is the total value of assets in multisig *custody*: multisig software holds +assets in custody accounts rather than a DeFi liquidity pool, so +total-value-locked (TVL) is not the applicable metric. + +Custodied-value figures (each with its basis and caveats): + +| Custody layer | Value in custody | Basis and caveats | +| ------------- | ---------------- | ----------------- | +| Safe (EVM) | **US$60B+** | Self-reported by Safe, accessed 2026-08-03: over US$60B secured across 57M+ deployed accounts, US$1T+ cumulative volume processed ([safe.global](https://safe.global)). Lower bound at best; protocol-reported. | +| Squads v4 (Solana) | **US$15B+** | Self-reported by Squads Labs, accessed 2026-08-03: over US$15B secured across 450+ teams ([squads.xyz/protocol](https://squads.xyz/protocol)). Protocol-reported. | +| Bitcoin native multisig (P2WSH proxy) | **~US$86.5B** | 1,365,834 BTC held in P2WSH outputs ([Glassnode supply by output type](https://studio.glassnode.com/charts/supply.SupplyByTxoutType?a=BTC), 2026-04-05 snapshot; subscription data, not independently verifiable from public sources) × US$63,364/BTC ([BitInfoCharts](https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html), 2026-08-03). P2WSH is used almost exclusively for multisig or complex scripts, making it the closest observable proxy for Bitcoin multisig custody. The older P2SH type (~3.96M BTC) is not a usable proxy because it mixes multisig with nested-SegWit single-sig and exchange cold wallets indistinguishably. | + +These figures indicate orders of magnitude, not precise totals. They establish +that value in multisig custody is on the order of **US$100B+** across the three +ecosystems today. | Implementation | Ecosystem / Layer | Stars | Last commit | Licence | | --------------------------------------------------------------- | ------------------------------ | -------- | ----------- | --------------------------- | @@ -70,6 +82,12 @@ multisig. | 9 | Coordination content: the discussion and signing messages exchanged between signers | Yes (off-chain by nature) | No researched on-chain multisig addresses this. Safe's transaction service leaks proposal metadata to whoever runs the relay. Bitcoin coordinators use an external channel (email, SD card, QR). | | 10 | Co-signing social graph: that this set of accounts jointly administers a multisig | Yes | Not addressed by any researched multisig. On account-model chains it is directly readable from the on-chain signer set (item 2); on Bitcoin it is inferable at spend. | +Note that "private" and "inspectable" are not mutually exclusive. Several of +these items (configuration, holdings, activity) are exactly what a DAO's +membership, or a company's auditors, may need to inspect on an ongoing basis; +LEZ key separation makes such selective inspection possible for a private +account (sections 2.1 and 2.2). + The prose below explains each item's cross-ecosystem behaviour precisely. ### 1.1 Existence, members, threshold (items 1-3) @@ -78,30 +96,34 @@ On the account-model chains, these three items are inseparable from how the quorum is enforced. Safe stores its owner set as a linked list and its threshold as a storage slot; Squads stores its members and threshold in a settings account; ZeroDev Kernel stores guardian addresses and weights in contract -storage. In all three, the chain must read this state to enforce the rule, so -the state is public by construction. See \[[patterns/squads-permission-model]\] -and the Safe contract architecture note \[[tools/safe-smart-account]\]. +storage (see the [Squads settings program +state](https://github.com/Squads-Protocol/smart-account-program/blob/main/programs/squads_smart_account_program/src/state/settings.rs), +the [Safe smart account +contracts](https://github.com/safe-global/safe-smart-account), and the [ZeroDev +Kernel](https://github.com/zerodevapp/kernel)). In all three, the chain must +read this state to enforce the rule, so the state is public by construction. Bitcoin native script (P2SH / P2WSH) reveals the full script (all public keys and the threshold) at spend time. Taproot changes this: a key-path spend using MuSig2 reveals nothing (see section 3), while a script-path spend reveals only the executed leaf and hides sibling leaves via the Merkle tree -(\[[patterns/taproot-key-path-musig2]\]). +([BIP-341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki), +[BIP-327](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki)). FROST is the outlier: the threshold is enforced cryptographically off-chain, and the chain sees a single Schnorr signature. Signer count, threshold, and the fact -that the account is a multisig at all are invisible -(\[[patterns/privacy-landscape]\]). +that the account is a multisig at all are invisible ([Komlo & Goldberg, +FROST](https://eprint.iacr.org/2020/852)). ### 1.2 Approval attribution and pending proposals (items 4-5) Squads persists each approval as separate on-chain state before execution, which produces a live, queryable pending-proposal view: any observer can see who has -approved and who has not, in real time -(\[[patterns/squads-transaction-lifecycle]\]). Safe typically collects -signatures off-chain and presents them together in the final `execTransaction` -call; owners may optionally record consent early with the on-chain `approveHash` -function. +approved and who has not, in real time (see the [Squads +smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). +Safe typically collects signatures off-chain and presents them together in the +final `execTransaction` call; owners may optionally record consent early with +the on-chain `approveHash` function. It is worth stating precisely what this difference is and is not. Both models yield an on-chain, verifiable record of who authorised an action *after it @@ -112,8 +134,9 @@ Squads makes approvals public before execution as a live pending view; Safe does not. This is a coordination-visibility difference, not an audit-trail advantage of one over the other. -A separate and distinct property, noted in the Bybit analysis -(\[[patterns/security-incidents-safe]\]), is *intent verifiability at signing +A separate and distinct property, noted in the [Check Point Bybit +analysis](https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/), +is *intent verifiability at signing time*: with off-chain signature collection there is no on-chain record that a signer intended the transaction they actually signed, which is the gap both the Bybit (February 2025, ~US$1.5B) and WazirX (July 2024, ~US$235M) incidents @@ -139,12 +162,12 @@ Coordination content is off-chain in every ecosystem, because signing protocols define message formats but not transports (see section 4). What differs is what the transport leaks. Bitcoin coordinators (Sparrow, Specter) exchange partially signed transactions over a channel the user chooses (SD card, QR, USB, file -share) and add no transport of their own -(\[[patterns/inband-signing-coordination]\]). Safe's self-hosted transaction +share) and add no transport of their own. Safe's self-hosted transaction service is a purpose-built relay; whoever operates it sees pending transaction -hashes, collected signatures, and which owners have approved -(\[[patterns/off-chain-signature-relay]\], -\[[patterns/safe-service-architecture]\]). +hashes, collected signatures, and which owners have approved (see the +[safe-transaction-service](https://github.com/safe-global/safe-transaction-service) +repository and the [Safe service +architecture](https://docs.safe.global/core-api/service-architecture) docs). The co-signing social graph (that a particular set of accounts jointly administers one multisig) is not treated as a distinct privacy concern by any @@ -159,7 +182,9 @@ it is what makes every "yes" in the section 1 table possible. It is a description of the platform, not a proposed design. Source: Logos documentation, "Introduction to the Logos Execution Zone" -(https://docs.logos.co/lez), accessed 2026-07-07. +(https://docs.logos.co/lez), accessed 2026-07-07, extended with the +`logos-blockchain/logos-execution-zone` codebase sources cited in section 2.1, +accessed 2026-08-03. The LEE separates persistent state into two kinds of account, and runs the **same program bytecode** over either: @@ -187,11 +212,73 @@ private-execution mode of the platform applied to the multisig's accounts. This is what distinguishes LEZ from every account-model chain in this survey, where the chain must read the quorum state in the clear in order to enforce it. +### 2.1 Shared private accounts: key separation and group keys + +Two further platform properties bear directly on multisig design, recorded here +from the `logos-blockchain/logos-execution-zone` codebase (accessed 2026-08-03). + +**Key separation: spending vs viewing.** A LEZ private account's key material +splits two kinds of authority (see +[secret_holders.rs](https://github.com/logos-blockchain/logos-execution-zone/blob/master/lee/key_protocol/src/key_management/secret_holders.rs) +and +[encryption/mod.rs](https://github.com/logos-blockchain/logos-execution-zone/blob/master/lee/state_machine/core/src/encryption/mod.rs)): + +- a **spending key** (the nullifier secret key), which authorises state + transitions; +- a **viewing key**, which decrypts the account's published ciphertext without + spending authority. + +Distributing the viewing key creates a **view-only auditor**: the recipient +learns the exact account state (balance, nonce, program data) and cannot move +funds. The cryptography supports this today, but it is not exposed as a wallet +command. Two caveats matter in practice: a shared viewing key **cannot be +revoked** (rotating the audience requires creating a fresh account and +migrating funds), and what the auditor sees is the exact state — there is no +coarser disclosure built in. + +**Group-owned shared accounts.** A private account can be shared through a +single Group Master Secret (GMS): every GMS holder derives *identical* spending +and viewing keys for the shared account (see +[group_key_holder.rs](https://github.com/logos-blockchain/logos-execution-zone/blob/master/lee/key_protocol/src/key_management/group_key_holder.rs) +and the wallet's +[group CLI](https://github.com/logos-blockchain/logos-execution-zone/blob/master/lez/wallet/src/cli/group.rs)). +The observed properties as of 2026-08-03: + +- Every GMS holder has **full spending authority**: the mechanism is effectively + N-of-N. No threshold share and no view-only share of the GMS exists; an M-of-N + rule would have to be layered on top, either by an on-chain program gating + spending or by a threshold scheme over the GMS-derived keys. +- Group membership is **not recorded on-chain**, and a group-owned account is + indistinguishable on-chain from a single-owner private account. +- There is **no member revocation**: excluding a member requires a fresh GMS, a + new account, and migrating all funds. Each private-to-private transfer is a + full private execution, benchmarked at ~127 s per step on an Apple M2 Pro + ([integration_bench.md](https://github.com/logos-blockchain/logos-execution-zone/blob/master/docs/benchmarks/integration_bench.md)). + +Wallet support for creating shared accounts, sealed invitations, funding, and +spending exists and is integration-tested +([shared_accounts.rs](https://github.com/logos-blockchain/logos-execution-zone/blob/master/integration_tests/tests/shared_accounts.rs)). + +### 2.2 Auditability configurations for a private treasury + +How inspectable a treasury must be differs by organisation: a corporate or +operational multisig typically needs a limited auditor group, while a DAO +treasury typically needs its whole membership — including members who join +later — to be able to verify that the treasury is secured the way the key +holders claim. The key-separation properties in section 2.1 make three +configurations available on LEZ: + +| Configuration | On-chain visibility | Who can audit | Notes | +| ---------------------------------------- | ------------------------------ | ------------------------------------------ | ---------------------------------------------------------------------------------------------------- | +| Public treasury account | Full (state visible to anyone) | Any observer | Simplest; sacrifices all holdings privacy | +| Private account + shared viewing key | Commitment only | Everyone holding the viewing key | Continuous inspection of exact state; doubles as standing proof of holding for new members; not revocable | +| Private account + zero-knowledge balance proof | Commitment only | Whoever the proof is published to | Would prove "balance ≥ X" against the on-chain commitment without revealing the exact balance; the LEE runs arbitrary RISC-V circuits, but no such circuit exists as of 2026-08-03 | + ## 3. Quorum privacy across ecosystems The degree to which a multisig's structure is visible follows directly from where the quorum is enforced. The pattern is consistent across every -implementation studied (\[[patterns/privacy-landscape]\]): +implementation studied: | Posture | How achieved | What remains visible | | ---------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------- | @@ -208,24 +295,26 @@ Two observations hold across the whole survey: 2. MuSig2 achieves this only for n-of-n (all signers must participate). Genuine k-of-n structural privacy on Bitcoin requires FROST, which as of 2026-07-06 - is still at BIP-draft stage and supported only by purpose-built hardware - (Frostsnap's ESP32-C3 device); no mainstream hardware wallet supports it - (\[[patterns/frost-taproot-privacy]\], \[[tools/bitcoin-frost-threshold]\]). + is still at BIP-draft stage ([ChillDKG BIP + draft](https://github.com/BlockstreamResearch/bip-frost-dkg)) and supported + only by purpose-built hardware (Frostsnap's ESP32-C3 device; see the + [Frostsnap FROST protocol + docs](https://frostsnap.com/docs/frost-protocol/)); no mainstream hardware + wallet supports it. The centralised industry "solution" to account-model privacy (a trusted relayer or co-processor that manages signer identity off-chain and presents a single abstract signer on-chain) trades sovereignty for privacy. Community proposals for private Safe ownership (zkSafe, Semaphore-based anonymous signer modules) exist but none reached production sovereign tooling; they required either a -trusted setup or a centralised coordinator (\[[patterns/privacy-landscape]\]). +trusted setup or a centralised coordinator. ## 4. Coordination: how signers reach quorum Signing coordination is either **in-band** (the signing-round messages flow through the same protocol or network as the final transaction) or **out-of-band** (signers exchange signing material through a medium external to -the protocol). The split follows the execution model -(\[[patterns/inband-signing-coordination]\]): +the protocol). The split follows the execution model: | Implementation | Coordination mode | Channel | | ---------------------------- | ----------------- | ------------------------------------------------------------------------------------------------- | @@ -240,9 +329,11 @@ Three facts about coordination bear on a product decision: - **Bitcoin's PSBT (BIP-174/370) is a container format, not a transport.** It defines how to package a partially-signed transaction but specifies no way to - deliver it between signers. Sparrow and Specter document several transfer - methods precisely because none is built in - (\[[patterns/psbt-coordinator-pattern]\]). + deliver it between signers + ([BIP-174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki), + [BIP-370](https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki)). + Sparrow and Specter document several transfer methods precisely because none + is built in. - **Account-model chains can coordinate in-band by storing coordination state on-chain,** as Squads does with proposal and approval accounts. Safe's @@ -253,11 +344,12 @@ Three facts about coordination bear on a product decision: - **Threshold-signature schemes carry their own session protocol.** FROST's DKG and signing rounds are a structured message exchange that runs within the protocol; a coordinator app (or a peer-to-peer layer) implements it without - any external messaging service (\[[patterns/frost-usb-coordination]\], - \[[patterns/frost-dkg-ceremony]\]). Frostsnap deliberately runs this over USB - serial rather than airgapped QR, because a k-of-n session over QR codes needs - many scans per transaction and the usability cost drives users to skip - verification. + any external messaging service (see the [Frostsnap design + decisions](https://frostsnap.com/docs/design-decisions/) docs and the + [ChillDKG BIP draft](https://github.com/BlockstreamResearch/bip-frost-dkg)). + Frostsnap deliberately runs this over USB serial rather than airgapped QR, + because a k-of-n session over QR codes needs many scans per transaction and + the usability cost drives users to skip verification. The product gap this exposes: no surveyed sovereign multisig provides an encrypted, metadata-resistant coordination channel. Coordination is either @@ -274,32 +366,42 @@ controls that shape what an operational multisig can express. - **Role separation.** Squads assigns each signer a three-bit permission mask (Initiate / Vote / Execute), so a proposing key need not be a voting key, and execution can be a separate role. Program invariants require at least one - signer with each permission and forbid an impossible threshold - (\[[patterns/squads-permission-model]\]). ZeroDev Kernel expresses roles as - weighted guardians, where the threshold is a minimum cumulative weight - (\[[patterns/weighted-multisig-onchain-vote]\]). + signer with each permission and forbid an impossible threshold (see the + [Squads settings program + state](https://github.com/Squads-Protocol/smart-account-program/blob/main/programs/squads_smart_account_program/src/state/settings.rs)). + ZeroDev Kernel expresses roles as weighted guardians, where the threshold is + a minimum cumulative weight + ([WeightedECDSAValidator.sol](https://github.com/zerodevapp/kernel/blob/master/src/validator/WeightedECDSAValidator.sol)). - **Time locks and cancellation.** Squads supports a per-multisig time lock (0 to about three months) enforced on-chain between approval and execution, and allows an approved proposal to be cancelled by a threshold of cancellation - votes before it executes (\[[patterns/squads-transaction-lifecycle]\]). Safe's - core contract has no time lock; it must be added as a guard or module - (\[[tools/safe-smart-account]\]). + votes before it executes (see the [Squads + smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). + Safe's core contract has no time lock; it must be added as a guard or module + ([safe-smart-account](https://github.com/safe-global/safe-smart-account)). - **Spending limits and policies.** Squads supports policy accounts with their own signer set and threshold for specific action types, and spending-limit - authorities (\[[patterns/squads-policy-framework]\]). Safe offers an Allowance - Module for spending limits. + authorities (see the + [smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). + Safe offers an Allowance Module for spending limits. - **Extensibility, and its cost.** Safe's guard and module system lets arbitrary contracts hook execution (guards) or execute without the M-of-N check - (modules) (\[[patterns/guard-module-system]\]). This is powerful and - dangerous: a module has unlimited authority, and the SquidRouter incident (May - 2026, ~US$3.2M) drained 86 Safes through a vulnerable third-party module that - owners had enabled (\[[patterns/security-incidents-safe]\]). ERC-4337 uses a - modular validator-plugin model with a defined install/uninstall lifecycle - (\[[patterns/erc7579-module-lifecycle]\], - \[[patterns/modular-validator-plugin]\]). + (modules) (see + [GuardManager.sol](https://github.com/safe-global/safe-smart-account/blob/main/contracts/base/GuardManager.sol) + and + [ModuleManager.sol](https://github.com/safe-global/safe-smart-account/blob/main/contracts/base/ModuleManager.sol)). + This is powerful and dangerous: a module has unlimited authority, and the + SquidRouter incident (May 2026, ~US$3.2M) drained 86 Safes through a + vulnerable third-party module that owners had enabled + ([Cryptopolitan + report](https://www.cryptopolitan.com/3-2m-drained-gnosis-safes-hack-base-ethereum/)). + ERC-4337 uses a modular validator-plugin model with a defined + install/uninstall lifecycle + ([ERC-7579](https://eips.ethereum.org/EIPS/eip-7579); [ZeroDev + Kernel](https://github.com/zerodevapp/kernel)). ## 6. Composition: how a multisig triggers actions @@ -308,11 +410,13 @@ implementations delegate execution rather than embedding target logic: - **Safe** executes an arbitrary `to` / `value` / `data` call (or delegatecall) through `execTransaction`, and batches multiple sub-calls through the - MultiSend library (\[[tools/safe-smart-account]\]). + MultiSend library + ([safe-smart-account](https://github.com/safe-global/safe-smart-account)). - **Squads** executes a stored instruction against a target program through a vault cross-program invocation, and supports batches executed sequentially - after a single approval (\[[patterns/squads-transaction-lifecycle]\]). + after a single approval + ([smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). - **The Logos public multisig sample app** (`logos-co/lez-multisig`) follows the Squads model on LEZ: a proposal stores a serialised instruction and target @@ -333,18 +437,21 @@ Two operational facts recur across the survey and bear on any real deployment: - **Hardware-wallet support is uneven.** Bitcoin has the broadest coverage: PSBT and the hardware wallet interface (HWI) support Coldcard, Trezor, Ledger, - Jade, BitBox02, and many airgapped signers - (\[[patterns/airgapped-signing-pattern]\]). EVM signing uses EIP-712 typed - data on Ledger, Trezor, and Keystone. Solana hardware signing requires - blind-signing in practice. FROST supports only Frostsnap's purpose-built - device, no mainstream hardware wallet. + Jade, BitBox02, and many airgapped signers (see the + [Sparrow](https://github.com/sparrowwallet/sparrow) and + [Specter](https://github.com/cryptoadvance/specter-desktop) documentation). + EVM signing uses EIP-712 typed data on Ledger, Trezor, and Keystone. Solana + hardware signing requires blind-signing in practice. FROST supports only + Frostsnap's purpose-built device, no mainstream hardware wallet. - **Sovereignty has different costs per stack.** Bitcoin coordinators need a Bitcoin Core or Electrum backend. Safe can run as a full Docker stack (many services) or CLI-only with no infrastructure. Squads needs only an RPC node. - ERC-4337 requires a bundler, which must be separately self-hosted or is - defaulted to a hosted provider (\[[patterns/bundler-liveness-dependency]\], - \[[patterns/server-first-coordinator-pattern]\]). + ERC-4337 requires a bundler + ([ERC-4337](https://eips.ethereum.org/EIPS/eip-4337); [eth-infinitism + bundler](https://github.com/eth-infinitism/bundler), [Pimlico + alto](https://github.com/pimlicolabs/alto)), which must be separately + self-hosted or is defaulted to a hosted provider. ## 8. Summary of observations @@ -352,6 +459,11 @@ Two operational facts recur across the survey and bear on any real deployment: on every account-model chain surveyed, most of them are public by construction because the chain must read the quorum to enforce it. +- The value in multisig custody is large and measurable: Safe self-reports + US$60B+ and Squads US$15B+ (protocol-reported, 2026-08-03), and the closest + observable Bitcoin native-multisig proxy (P2WSH outputs) held ~US$86.5B at + 2026-08-03 prices. + - The only implementations that keep multisig structure private (FROST, MuSig2 n-of-n) do so by moving the quorum off-chain into a cryptographic session, at the cost of hardware and tooling immaturity and, for MuSig2, an n-of-n-only @@ -362,6 +474,13 @@ Two operational facts recur across the survey and bear on any real deployment: threshold, approvals, action) published only as commitments, without a trusted coordinator and without abandoning k-of-n. +- LEE key separation makes a private account selectively inspectable: sharing + the viewing key yields a view-only auditor (irrevocable short of account + migration). LEZ group-shared accounts are effectively N-of-N with no + on-chain membership record and no revocation, so M-of-N must be layered on + top (section 2.1); three auditability configurations are available to a + treasury depending on its audience (section 2.2). + - "On-chain versus off-chain approval" is a coordination-visibility choice, not an audit-trail trade-off: both models yield an on-chain authorisation record at execution. @@ -373,17 +492,32 @@ Two operational facts recur across the survey and bear on any real deployment: | Source | URL | Access date | | ---------------------------------------- | ------------------------------------------------------------------------------------ | ----------- | -| research-multisig-sovereign vault | https://github.com/marclawclaw/research-multisig-sovereign | 2026-07-06 | | Introduction to the Logos Execution Zone | https://docs.logos.co/lez | 2026-07-07 | +| Logos Execution Zone codebase (key protocol, encryption, wallet group CLI, shared-account integration tests, benchmarks) | https://github.com/logos-blockchain/logos-execution-zone | 2026-08-03 | +| Safe (protocol-reported custody figures) | https://safe.global | 2026-08-03 | +| Squads protocol (protocol-reported custody figures) | https://squads.xyz/protocol | 2026-08-03 | +| Glassnode supply by output type (subscription data) | https://studio.glassnode.com/charts/supply.SupplyByTxoutType?a=BTC | snapshot 2026-04-05 | +| BitInfoCharts (BTC price reference) | https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html | 2026-08-03 | | Squads smart-account-program | https://github.com/Squads-Protocol/smart-account-program | 2026-07-06 | | Safe smart account | https://github.com/safe-global/safe-smart-account | 2026-07-06 | +| Safe transaction service | https://github.com/safe-global/safe-transaction-service | 2026-07-06 | +| Safe service architecture (docs) | https://docs.safe.global/core-api/service-architecture | 2026-07-06 | | Frostsnap | https://github.com/frostsnap/frostsnap | 2026-07-06 | +| Frostsnap FROST protocol docs | https://frostsnap.com/docs/frost-protocol/ | 2026-07-06 | +| Frostsnap design decisions | https://frostsnap.com/docs/design-decisions/ | 2026-07-06 | +| FROST paper (Komlo & Goldberg) | https://eprint.iacr.org/2020/852 | 2026-07-06 | +| ChillDKG BIP draft | https://github.com/BlockstreamResearch/bip-frost-dkg | 2026-07-06 | | ZeroDev Kernel | https://github.com/zerodevapp/kernel | 2026-07-06 | | Sparrow Wallet | https://github.com/sparrowwallet/sparrow | 2026-07-06 | | Specter Desktop | https://github.com/cryptoadvance/specter-desktop | 2026-07-06 | | rust-bitcoin | https://github.com/rust-bitcoin/rust-bitcoin | 2026-07-06 | +| BIP-174 (PSBT) | https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki | 2026-07-06 | | BIP-327 (MuSig2) | https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki | 2026-07-06 | | BIP-341 (Taproot) | https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki | 2026-07-06 | +| BIP-370 (PSBT v2) | https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki | 2026-07-06 | +| ERC-4337 (account abstraction) | https://eips.ethereum.org/EIPS/eip-4337 | 2026-07-06 | +| ERC-7579 (modular smart accounts) | https://eips.ethereum.org/EIPS/eip-7579 | 2026-07-06 | | Bybit incident analysis (Check Point) | https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/ | 2026-07-06 | | WazirX hack analysis (QuillAudits) | https://www.quillaudits.com/blog/hack-analysis/wazirx-235m-hack | 2026-07-06 | +| SquidRouter module incident (Cryptopolitan) | https://www.cryptopolitan.com/3-2m-drained-gnosis-safes-hack-base-ethereum/ | 2026-07-06 | | logos-co/lez-multisig | https://github.com/logos-co/lez-multisig | 2026-07-07 | From a5aa5b3cc0e72f728cf4d6ebc9df607f796e568d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 3 Aug 2026 14:44:47 +1000 Subject: [PATCH 03/14] RFP-005: address PR #113 review --- RFPs/RFP-005-multisig-and-coordination.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 8fb2e9a6..70c11f8f 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -20,8 +20,8 @@ Build a production-ready M-of-N multisig program on the Logos Execution Zone (LEZ), together with an in-band coordination channel so signers can propose, deliberate, collect approvals, and reach quorum without leaving the application. A multisig is the execution layer for shared custody, treasuries, -and DAOs: the Logos launch-day Private Multisig app and the Private DAO both -depend on it. The program is designed and implemented from scratch for LEZ, +and DAOs: a Private DAO Lambda Prize will be published and expected to use the +this RFP's implementation. The program is designed and implemented from scratch for LEZ, taking as its baseline the properties LEZ makes uniquely possible: multisig state that is private by default, and a coordination channel that is encrypted and metadata-resistant. From 0f45915d8f00dba91ecfbecb00672d3bb5d04c54 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 13:02:20 +1000 Subject: [PATCH 04/14] RFP-005: ground the RFP in verified LEZ behaviour Verified every platform claim against the LEZ codebase and corrected the document where it diverged from reality. Vault architecture: the settled baseline claimed k-of-N enforcement lives at the program layer over a GMS-derived shared account. It does not. A regular GMS-derived account carries no program binding, so any single holder can spend it without the multisig program being invoked; such a multisig would be advisory, not enforcing. The baseline is now a private PDA derived under the multisig program's ID, where the one-way program_owner latch means only that program's verified execution can decrease the balance. What was Option A is now the baseline; the GMS is demoted to coordination and viewing. Corrected against source: - Private throughput is ~4 tx/block, not one; ~220 KiB receipts make block size the binding constraint, and proving costs minutes per transaction client-side. - No clock is readable from the private path. F.2, F.7 and F.8 must be built on timestamp validity windows. - Proof of holding needs a second purpose-built circuit that does not exist; demoted to a soft requirement. - The account nonce is an nsk-keyed hash chain, so R.2 replay binding must live in program account data. - Added the private-account padding ceiling, the pre-initialisation window, and the third PDA binding path needed for vault funding. - F.3 constrained to statically declared call graphs. Resolved the custody contradiction: neither model is unambiguously better, so both now state what they cost. All-members custody forfeits F.6 execute separability; operator custody forfeits the no-trusted-coordinator property. LP-0002 is an open, unclaimed prize to build a private M-of-N multisig, not a delivered capability, and its anonymous-approval design differs from R.1's attributed approvals. Corrected the dependency reason and added it to Resources as design-space reading. Also flagged that the lez-multisig prior art is incompatible with private accounts. Retier to XL to match the sixteen deliverables across five disciplines, and drop the unfilled funding placeholder. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 2 +- RFPs/RFP-005-multisig-and-coordination.md | 748 +++++++++++++++------- 2 files changed, 529 insertions(+), 221 deletions(-) diff --git a/README.md b/README.md index 3de5cb3c..13602311 100644 --- a/README.md +++ b/README.md @@ -80,7 +80,7 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | closed | Developer Tooling & Infrastructure | Closed | | RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | closed | Applications & Integrations | Closed | | RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | closed | Applications & Integrations | Closed | -| RFP-005 | [Multisig and Coordination](RFPs/RFP-005-multisig-and-coordination.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-005 | [Multisig and Coordination](RFPs/RFP-005-multisig-and-coordination.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | closed | Applications & Integrations | Closed | diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 70c11f8f..fb76b708 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -1,14 +1,11 @@ --- id: RFP-005 title: Multisig and Coordination -tier: L -funding: $XXXXX +tier: XL status: open dependencies: - id: LP-0002 - reason: LP-0002 demonstrates an M-of-N multisig running over LEE private - accounts; this RFP's private-by-default posture relies on that execution - model being production-available on LEZ. + reason: LP-0002 is an open prize for a private M-of-N multisig primitive on LEZ; it is adjacent work, not a delivered capability, and no end-to-end multi-party authorization flow exists in the LEZ codebase today. Its anonymous-approval design differs from this RFP's attributed approvals (R.1), so it is not a drop-in foundation. What this RFP actually requires is private-account execution, which is available. category: Applications & Integrations --- @@ -18,24 +15,22 @@ category: Applications & Integrations Build a production-ready M-of-N multisig program on the Logos Execution Zone (LEZ), together with an in-band coordination channel so signers can propose, -deliberate, collect approvals, and reach quorum without leaving the -application. A multisig is the execution layer for shared custody, treasuries, -and DAOs: a Private DAO Lambda Prize will be published and expected to use the -this RFP's implementation. The program is designed and implemented from scratch for LEZ, -taking as its baseline the properties LEZ makes uniquely possible: multisig -state that is private by default, and a coordination channel that is encrypted -and metadata-resistant. +deliberate, collect approvals, and reach quorum without leaving the application. +A multisig is the execution layer for shared custody, treasuries, and DAOs. The +program is designed and implemented from scratch for LEZ, taking as its baseline +the properties LEZ makes uniquely possible: multisig state that is private by +default, and a coordination channel that is encrypted and metadata-resistant. Multisig is the single most widely used custody primitive in the ecosystem, and -the value in multisig custody today is immense. Safe (formerly Gnosis Safe), -the dominant standard on Ethereum, is deployed across 86 networks and -self-reports over US$60B in assets secured; Squads, the Solana analogue, -self-reports over US$15B (protocol-reported figures, 2026-08-03). Both are -fully transparent by construction: members, threshold, every approval, and -every action are public on-chain state, because the chain must read the quorum -in order to enforce it. That transparency has been an attack surface: the -Bybit (February 2025, ~US$1.5B) and WazirX (July 2024, ~US$235M) incidents -both targeted fully visible Safe configurations at the signing layer. +the value in multisig custody today is immense. Safe (formerly Gnosis Safe), the +dominant standard on Ethereum, is deployed across 86 networks and self-reports +over US$60B in assets secured; Squads, the Solana analogue, self-reports over +US$15B (protocol-reported figures, 2026-08-03). Both are fully transparent by +construction: members, threshold, every approval, and every action are public +on-chain state, because the chain must read the quorum in order to enforce it. +That transparency has been an attack surface: the Bybit (February 2025, +~US$1.5B) and WazirX (July 2024, ~US$235M) incidents both targeted fully visible +Safe configurations at the signing layer. The team building this should have deep experience in multisig or threshold custody design, Rust program development for a RISC-V or zkVM target, and @@ -45,8 +40,7 @@ applied cryptography. Shared custody is a precondition for organisations to operate on Logos. Without a production multisig, there is no treasury, no DAO execution layer, and no -shared control of protocol admin authorities. The launch-day Private Multisig -app and the Private DAO are blocked on it. +shared control of protocol admin authorities. LEZ also makes it possible to close a gap no sovereign multisig has closed. Every existing implementation that keeps multisig structure private (FROST, @@ -54,9 +48,11 @@ MuSig2 n-of-n) does so by moving the quorum off-chain into a cryptographic session, at the cost of hardware immaturity and, for MuSig2, an n-of-n-only limitation. Every implementation that keeps the quorum on-chain is transparent. On LEZ, the same multisig program can run over private accounts, so the chain -records only a commitment to the post-state and a validity proof, without a -trusted coordinator and without giving up k-of-n. This RFP is the vehicle for -delivering that. +records only a commitment to the post-state and a validity proof, without giving +up k-of-n. Under the all-members key-custody model it achieves this without a +trusted coordinator; the alternative custody model trades that property away for +stricter role separation, and the choice is left to the proposer. This RFP is +the vehicle for delivering that. ## ✅ Scope of Work @@ -64,64 +60,101 @@ delivering that. #### Functionality -1. Implement an M-of-N multisig program on LEZ. A multisig is created with N - members and a threshold M; an action requires at least M approvals before it - can execute. Members, threshold, and the action set are configurable at - creation. -2. Support the full proposal lifecycle. Proposals and approvals are coordinated - off-chain through the per-multisig coordination room (requirement F.8): a - member publishes a proposal to the room; members approve or reject - asynchronously; once M approvals are collected the action can be executed, - and the program verifies the collected approvals at execution. Proposals - carry an expiry after which the program rejects execution. -3. Execute approved actions on any arbitrary program deployed in the given LEZ: - a proposal designates a target program and an instruction, and on execution - the multisig program invokes the target on the multisig's authority. The - multisig never modifies another program's state directly. The design must - not special-case any particular target program. -4. Support configuration changes (add or remove a member, change the threshold) - through the same M-of-N approval flow, so structural changes cannot bypass - the quorum. -5. Support role separation among members so that the ability to propose, to - approve, and to execute can be assigned independently. At minimum, a - proposing key need not be an approving key. -6. Support an optional per-multisig time lock: a configurable delay between an - action reaching quorum and becoming executable, enforced by the program. A - time lock of zero means immediate execution. -7. Support an optional spending-limit policy: a member (or sub-quorum) may - execute transfers up to a configured limit without the full M-of-N approval. -8. Provision an end-to-end-encrypted coordination room per multisig using the - Logos chat module, scoped to the multisig's members. The room carries both - human deliberation and machine coordination: proposals are published to the - room, member approvals are collected through it, and the resulting approval - package is presented to the program at execution. See the Coordination - Architecture section. -9. Run the multisig private by default: the program runs over LEE private - accounts so that the multisig data items listed in the Privacy Architecture - section are not published on-chain. Support the auditability and - transparency options defined there: an operator-selectable fully public - posture, and selective disclosure of a private multisig's state to a chosen - audience via view keys. +01. Implement an M-of-N multisig program on LEZ. A multisig is created with N + members and a threshold M; an action requires at least M approvals before it + can execute. Members, threshold, and the action set are configurable at + creation. +02. Support the full proposal lifecycle. Proposals and approvals are coordinated + off-chain through the per-multisig coordination room (requirement F.9): a + member publishes a proposal to the room; members approve or reject + asynchronously; once M approvals are collected the action can be executed, + and the program verifies the collected approvals at execution. Proposals + carry an expiry after which the program rejects execution. Verifying + approvals inside the program requires vendoring a signature verifier into + the guest environment, which has no such primitive today; see Platform + Dependencies. +03. Execute approved actions against other programs deployed in the given LEZ, + via chained calls. Note two platform constraints: every callee must be + declared as a dependency at proof-construction time with its program binary + available to the prover, and a transaction is capped at a small number of + chained calls in total (not nesting depth). "Arbitrary" therefore means any + statically known call graph, not any call graph discovered at execution + time. Proposers must state how a proposal's target set is declared and + verified against these limits. +04. Provide a registry for proposal code and target programs so any client can + confirm what instructions a proposal's bytes represent and what program they + invoke, without relying on a single trusted source. "Without relying on a + single trusted source" means the mapping must be independently verifiable by + any client, for example by content-addressing entries so a client checks the + binding itself rather than trusting the publisher. Building a decentralised + governance layer for registry membership is out of scope. Note that + Usability requirement U.6 (decode the action before signing) can only be as + complete as this registry's coverage; proposers must state what a client + displays when a target program is not registered. +05. Support configuration changes (add or remove a member, change the threshold) + through the same M-of-N approval flow, so structural changes cannot bypass + the quorum. +06. Support role separation among members so that the ability to propose and the + ability to approve can be assigned independently. At minimum, a proposing + key need not be an approving key. Note that "execute" is separable only + under the operator custody model: where every member holds the vault + spending key, any member can submit a transaction, and the program can only + decline to count them as an approver. Documentation must state which + guarantee the chosen custody model actually delivers, rather than implying + execution is gated when it is not. +07. Support an optional per-multisig time lock: a configurable delay between an + action reaching quorum and becoming executable. A time lock of zero means + immediate execution. Because no clock is readable from the private path (see + Platform Dependencies), this must be enforced through timestamp validity + windows and durable program state, and the proposer must document the + resulting security properties, including what a prover can and cannot + influence about the effective unlock time. +08. Support an optional spending-limit policy: a member or sub-quorum may + execute transfers up to a configured limit without the full M-of-N approval. + This requirement deliberately weakens the vault's security below the limit, + and it compounds with custody: where every member holds the vault spending + key, the limit accounting in the program is the only control standing + between a single member and the funds. Per-period limits additionally + require a time source the private path does not provide, and per-member + accumulators consume private-account slots against the padding ceiling + described in Platform Dependencies. Proposers must justify the account + layout and state the residual risk. Implementing this as a fixed lifetime + allowance rather than a renewing per-period limit is acceptable and avoids + the time dependency. +09. Provision an end-to-end-encrypted coordination room per multisig using the + Logos chat module, scoped to the multisig's members. The room carries both + human deliberation and machine coordination: proposals are published to the + room, member approvals are collected through it, and the resulting approval + package is presented to the program at execution. See the Coordination + Architecture section. +10. Run the multisig private by default: the program runs over LEZ private + accounts so that the multisig data items listed in the Privacy Architecture + section are not published on-chain. Support the auditability and + transparency options defined there: an operator-selectable fully public + posture, and selective disclosure of a private multisig's state to a chosen + audience. #### Usability 1. Provide an SDK that can be used to build Logos modules for interacting with the multisig (create, propose, approve, reject, execute, manage members and policies). -2. Provide a Logos mini-app GUI with local build instructions, downloadable - assets, and loadable in Logos app (Basecamp) via git repo. The mini-app must - surface the per-multisig coordination room alongside the proposal list. -3. Provide a CLI that covers core functionality of the program (create, propose, - approve, reject, execute, and configuration changes). The CLI may have fewer - features than the GUI mini-app but must support all essential operations. -4. Provide an IDL for the LEZ program, preferably using the +2. Provide a Logos mini-app GUI, built as QML with a C++ backend module, with + local build instructions, downloadable assets, and loadable in Logos app + (Basecamp) via git repo. The mini-app must surface the per-multisig + coordination room alongside the proposal list. +3. Provide a CLI that uses the Logos core headless framework and covers core + functionality of the program (create, propose, approve, reject, execute, and + configuration changes). The CLI may have fewer features than the GUI mini-app + but must support all essential operations. +4. Provide an IDL for the LEZ program, using the [SPEL framework](https://github.com/logos-co/spel). 5. Documentation must clearly explain, for each action, what information is public and what is private under the multisig's configured posture (which of the data items enumerated in the Privacy Architecture section are published on-chain and which are not), so a multisig operator understands exactly what - an observer can see, including what becomes visible to an audience once a - view key is shared with it. + an observer can see, including what becomes visible to an audience under each + disclosure mechanism. 6. Before a member signs an approval, the mini-app must display the exact action that approval authorises (target program, decoded instruction, amounts), so the member verifies what they are signing rather than a UI-rendered summary. @@ -137,20 +170,42 @@ delivering that. distinct valid approvals from current members on exactly the action being executed; no approval is double-counted or replayed across proposals, and an action cannot execute with fewer than M valid approvals. + 2. A configuration change (member set or threshold) must invalidate approval sets gathered under the old configuration: an approval collected before the change must not count toward quorum after it, unless the action had already - reached quorum and been scheduled for execution. + reached quorum and entered its time-lock delay or been submitted for + execution. The proposal must define precisely which of those points is the + cutoff, and what happens to a pending action when a member is removed during + a time-lock delay. + + The private account nonce cannot carry this binding. The circuit overwrites + it on every private update with a value derived from the account's spending + key, so it is an opaque hash chain rather than a readable counter: the + program cannot read a meaningful sequence number from it, cannot predict the + post-state value, and every spending-key holder can compute the entire future + chain. Replay and configuration binding must therefore be carried in the + program's own account data, for example a configuration epoch that increments + on every change and that every approval commits to. #### Performance -1. Each on-chain operation (create, execute, configuration change) completes - within a single LEZ transaction. Proposal publication and approval - collection happen in the coordination room, not on-chain. -2. Compute unit usage and transaction size of each on-chain operation must be - documented and benchmarked against LEZ devnet limits. Because execution runs - in the private path by default, the per-proof cost and the per-block private - transaction throughput must be measured and reported. +1. Compute unit usage, transaction size, and client-side proving time for each + on-chain operation must be documented and benchmarked against LEZ devnet + limits. All benchmarks must be produced with **real proving**. Development + mode produces stub receipts orders of magnitude smaller and faster than real + ones, and figures gathered that way are meaningless for capacity planning; + benchmarks submitted from development mode will not be accepted. +2. The RISC Zero cycle cost of in-guest approval verification must be + benchmarked and reported as a function of M, since no signature-verification + primitive exists in the guest environment today and the vendored + implementation is on the critical path for proof size and cost. Report the + largest M that remains viable within block limits, presented as a step + function (see Platform Dependencies on power-of-two cycle bucketing). **M of + at least 5 must remain viable** for the deliverable to be considered + complete; if the benchmark shows otherwise, the finding itself is a + reportable result and triggers a scope discussion rather than silent delivery + of a lower ceiling. #### Supportability @@ -158,10 +213,13 @@ delivering that. 2. End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI. 3. CI must be green on the default branch. -4. Every hard requirement in Functionality, Usability, Reliability, and - Performance has at least one corresponding test, including a test that an - action cannot execute below threshold and a test that a configuration change - respects requirement R.2. +4. Every hard requirement in Functionality, Usability, and Reliability has at + least one corresponding test. At minimum this includes: an action cannot + execute below threshold; a configuration change respects requirement R.2; and + a vault cannot be drained through the pre-initialisation window described in + Platform Dependencies. Performance requirements are satisfied by reported + measurements rather than pass/fail tests, but the benchmark harness must be + committed and reproducible. 5. A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for creating a multisig, proposing, approving, and executing via CLI and front-end, including how the coordination room is @@ -174,6 +232,8 @@ delivering that. for the CLI, covering the core operator journey. 8. Provide Figma designs or equivalent for the mini-app GUI, including the proposal list and the coordination room. +9. Publish resulting modules in the + [Logos modules catalog](https://github.com/logos-co/logos-modules-release-base). ### Soft Requirements @@ -181,26 +241,18 @@ If possible. #### Functionality -1. Support batch proposals: a single proposal covering multiple actions that are - approved once and executed atomically or in sequence. -2. Support weighted approvals, where members carry numeric weights and the +1. Support weighted approvals, where members carry numeric weights and the threshold is a minimum cumulative weight. -3. Support zero-knowledge proof-of-holding: the multisig can prove its vault - holds at least a stated amount, verified against the on-chain commitment, - without revealing the exact balance (see the auditability options in Privacy - Architecture). - -### Out of Scope - -The following are explicitly excluded from this RFP: - -- A FROST or MuSig2 threshold-signature implementation. Structural privacy on - LEZ comes from running the multisig program over private accounts, not from - an off-chain threshold-signature session. A threshold scheme layered over - shared-account keys remains a documented future extension (see the Decision - for Review), but no threshold-signature implementation is delivered here. -- Recovery of a multisig whose members have lost quorum-many keys. Social or - time-locked key recovery is a separate concern and is not required here. +2. **Proof of holding.** Enable a multisig to demonstrate that its vault holds + at least a stated amount, verified against the on-chain commitment, without + revealing the exact balance. This is a soft requirement because it is not + expressible with today's primitives: the on-chain artefact is a hash + commitment over the whole account, so proving an inequality against it + requires a second, purpose-built zero-knowledge circuit that does not exist + and whose verifying key would need to be established and trusted. A proposer + may scope this as a research deliverable with its own budget, or document a + design for later implementation. A proposal that omits it entirely is not + penalised. ### Coordination Architecture @@ -208,8 +260,7 @@ Every multisig provisions one end-to-end-encrypted room using the Logos chat module, scoped to its members. The room is the single channel for both kinds of coordination traffic: -- **Human deliberation**: the discussion among signers about whether to - approve. +- **Human deliberation**: the discussion among signers about whether to approve. - **Machine coordination**: proposals are published to the room, and members' approvals (signatures over the proposal) are collected through it. Once M approvals are gathered, the approval package is submitted for execution; the @@ -230,51 +281,57 @@ is no live on-chain pending view, the client must reliably gather, retain, and present room state so signers always see the current proposal set and collected approvals. +Room membership and program membership are separate state and can diverge. +Removing a member through the M-of-N flow (F.5) changes the program's member +set, but does not by itself evict that member from the coordination room, and a +stale client may keep showing them as a participant. Proposals must state how +room membership is reconciled with program membership on every configuration +change, and what a removed member can still observe in the room until that +reconciliation completes. + ### Privacy Architecture -A multisig involves at least ten distinct data and metadata items: the -existence of the multisig, the member set, the threshold, per-signer approval -attribution, pending-proposal metadata, the action payload, the vault balance, -execution linkage, coordination content, and the co-signing social graph. On -LEZ, each of these can independently be public or private, because the Logos -Execution Environment runs the same program over public accounts (visible -on-chain) or private accounts (only a post-state commitment and validity proof -on-chain). +A multisig involves at least ten distinct data and metadata items: the existence +of the multisig, the member set, the threshold, per-signer approval attribution, +pending-proposal metadata, the action payload, the vault balance, execution +linkage, coordination content, and the co-signing social graph. On LEZ, each of +these can independently be public or private, because the Logos Execution +Environment runs the same program over public accounts (visible on-chain) or +private accounts (only a post-state commitment and validity proof on-chain). **Posture: private by default.** Under this RFP the multisig runs over private accounts by default, so none of the ten items is published in the clear; coordination content is always private (the E2EE room), and the co-signing social graph is not readable from chain state. Where identity is concerned, the -property in question is unlinkability between a user's account and its role in -a multisig, not concealment of the user. +property in question is unlinkability between a user's account and its role in a +multisig, not concealment of the user. **Auditability and transparency options.** Privacy is not the opposite of oversight, and different organisations need different audiences able to inspect -the multisig: a corporate or org multisig may need a limited auditor group, -while a DAO may need its entire membership to be able to audit. The program -must support: - -1. **Public posture (operator-selectable).** At creation the operator may - deploy the multisig fully public instead of private, for treasuries that - want anyone to be able to inspect configuration, holdings, and activity at - all times. -2. **Selective disclosure via view keys.** LEZ private accounts separate the - spending key from a viewing key that decrypts the account's on-chain state - without granting spending authority. Distributing the viewing key to a - defined audience (for example, to DAO members through the coordination room - or another member-restricted channel) lets that audience inspect the - multisig's holdings and configuration at any time, without making them - public and without granting spending power. A member holding the viewing key - can also demonstrate to a new joiner that the treasury holds what the key - holders claim, which serves as standing proof of holding. View-key - distribution is not currently exposed by the LEZ wallet, so the SDK must - implement it. A shared viewing key cannot be revoked: rotating the audience - requires migrating the multisig to a fresh account, and the documentation - must say so. +the multisig. The program must support: + +1. **Public posture (operator-selectable).** At creation the operator may deploy + the multisig fully public instead of private, for treasuries that want anyone + to be able to inspect configuration, holdings, and activity at all times. + +2. **Selective disclosure to a defined audience.** The program must enable a + private multisig to disclose its state (configuration, holdings, activity) to + a chosen audience without making that information public and without granting + spending power to that audience. + + The platform primitive for this is viewing-key sharing, and it is + all-or-nothing. A private account's note is a single encrypted blob covering + the whole account state, so sharing the viewing key reveals every field of + every note for that account, for all time, past and future. Disclosing the + threshold but not the balance, or 2026 activity but not 2025, is not + expressible by sharing keys alone. Anything finer must be constructed in the + program's account layout, for example by separating disclosable state into a + distinct account with its own viewing key. Proposers must state which + granularity they deliver and what an audience unavoidably learns. Documentation (Usability requirement U.5) must state the resulting public/private split explicitly for the configured posture, including who can -see what once a view key has been shared. +see what under each disclosure mechanism. ## ⚠ Platform Dependencies @@ -287,58 +344,250 @@ but a working on-chain deployment depends on the primitives below. The private-by-default posture requires running the multisig over LEE private accounts: post-state commitments, nullifiers, and Risc0 validity proofs. These -are core LEE features, demonstrated for an M-of-N multisig under LP-0002; -proposers should confirm the state of private-account support on LEZ devnet -against the Resources below before relying on it, including whether -program-derived private accounts are supported for the multisig's vault — that -property determines the options in the Decision for Review below. - -#### Shared private accounts (key separation and group keys) +are core LEE features, and the private-PDA lifecycle this RFP depends on is +covered by integration tests on LEZ `main`, for a single keyholder. Proposers +should confirm the state of private-account support on LEZ devnet against the +Resources below before relying on it. + +No end-to-end multi-party authorization flow exists in the LEZ repository today. +The primitives are present and the single-keyholder private-PDA lifecycle is +tested, but nothing demonstrates M-of-N in the program layer. This RFP +commissions the first such implementation. LP-0002 is an open prize covering +adjacent ground, but it is unclaimed and its design differs from this RFP's; see +Resources. + +#### Program-derived private PDAs (the enforcement mechanism) + +The vault is a private PDA derived under the multisig program's ID. This is what +makes M-of-N enforceable, and the mechanism has two parts, both present and +exercised on LEZ `main`: + +1. **Address binding.** A private PDA's account ID commits to the program: + `AccountId::for_private_pda(program_id, seed, npk, vpk, identifier)`. The + privacy-preserving circuit refuses any private-PDA pre-state whose npk has + not been proven to derive that account ID. Three binding paths exist: the + program's own `Claim::Pda(seed)`, a caller's `pda_seeds`, and an external + seed supplied directly as a circuit input. The third is what makes funding a + program-owned private PDA from another program possible, and proposers will + need it for vault funding. +2. **Ownership latch.** `validate_execution` permits a balance decrease only + when `account_program_owner == executing_program_id`. Once the vault's + `program_owner` is set to the multisig program, that latch is one-way: + ownership cannot be changed or reverted. Only the multisig program's verified + execution can move funds out. + +Enforcement therefore comes from the ownership latch, not from anything about +the key layer. A multisig program that asserts its M-of-N condition makes the +proof unconstructible when the condition fails. + +**The vault cannot be claimed by another program.** Because the account ID +commits to the program ID, and the claim path asserts that the account ID +re-derives from the *executing* program's own ID, a hostile program can only +claim accounts within its own namespace. Claiming the multisig's vault would +require a hash preimage collision. This is worth stating explicitly because the +circuit does not enforce authorization claims on private accounts generally: for +the private non-PDA path, `Claim::Authorized` is a deliberate no-op +("unauthorized private claiming is intentionally allowed"). That no-op does not +apply to the private-PDA claim path, which is address-bound. + +**What the circuit does not do.** It does not verify that a program's approval +predicate ran and returned true. It proves derivation-from-program plus the +seed/npk binding. The approval logic itself is the program's responsibility, and +the ownership latch is what forces the program to run at all. + +**Initialisation is security-critical.** The latch protects the vault only once +the multisig program has claimed it. An account that has been funded but not yet +claimed sits under the default program owner, where the balance-decrease rule +does not yet bind it to the multisig program, and any holder of the vault +spending key can move funds out before the program is ever involved. Vault +creation and first funding must therefore be atomic, or the design must make +pre-initialisation deposits impossible. Proposers must state how they achieve +this, and Reliability testing must cover it. + +**Vault key custody is an open design choice.** The circuit has no notion of an +npk that nobody holds: someone must hold the vault's nullifier secret key (nsk) +to construct the spend proof. Two models are viable and the proposer must choose +one and justify it (see Decisions for Review). + +#### Shared private accounts and group keys (not a multisig primitive) + +LEZ supports group-owned shared private accounts derived from a single 32-byte +Group Master Secret (GMS): every member independently derives the same account +keys (NSK/VSK/NPK/VPK). New members are admitted by sealing the GMS to their +public key and having them unseal it. + +**The GMS confers full spending authority and cannot be restricted to viewing.** +Because the derivation hands every holder the full nsk, and holding the nsk is +what permits a spend, distributing the GMS to N members distributes N copies of +full spending authority. It is not a multisig primitive and must not be used as +one. Where a view-only auditor is wanted, share the account's viewing key +instead — that is the mechanism that actually separates viewing from spending. + +Specifically, a **regular** (non-PDA) GMS-derived shared account carries no +program binding at all: its account ID is derived without a program ID, and its +`program_owner` ends up as the standard funding program. Any single GMS holder +can spend it directly without the multisig program ever being invoked. A +multisig built on that account shape would be advisory, not enforcing. + +Properties proposers should account for: + +- The key layer is effectively **1-of-N**: any GMS holder derives full spending + and viewing authority. There is no view-only or threshold share of the GMS. +- The GMS is a **root** secret. A holder derives keys for every account the + group creates under it, including accounts created after they joined, and can + re-seal the GMS to an arbitrary third party without the other members' + consent. +- Group membership is **not recorded anywhere** — not on-chain, and not in any + registry or distribution service. `invite` prints a sealed blob and `join` + accepts one; conveying it is entirely the operator's problem, and each + member's roster is independent local state that can silently diverge. +- There is **no member revocation**. Removing a member deletes only the caller's + own local copy; the removed member's GMS still derives working spending keys. + In-place GMS rotation is structurally impossible, because the account ID + commits to the derived npk and vpk — a new GMS is a different account. + Migration to a fresh GMS is the only path, it is not automated, and during the + sweep the removed member holds equal spending authority over the funds being + moved. They also retain permanent viewing access to the old account's history. The auditability options rely on LEE key separation: a private account has a -spending (nullifier) key and a viewing key, and sharing the viewing key yields -a view-only auditor. LEZ also provides group-owned shared private accounts -derived from a single shared group secret, whose semantics matter for the vault -design: every member of the group derives full spending authority (there is no -view-only or threshold share of the group secret), group membership is not -recorded on-chain, and there is no revocation short of migrating funds to a new -account. Proposers should confirm these properties against the LEZ -documentation and codebase before relying on them. +spending (nullifier) key and a viewing key, and sharing the viewing key yields a +view-only auditor. Note that the GMS itself cannot express this separation — any +GMS holder gets both. -#### Logos chat module +Proposers should confirm these properties against the LEZ codebase before +relying on them. + +#### Private-account count is part of the anonymity set -The per-multisig coordination room (Functionality requirement F.8) depends on -the Logos chat module. Proposers should confirm the module's availability and -its SDK surface for creating a member-scoped, end-to-end-encrypted room before -relying on it. +A privacy-preserving transaction pads its private inputs to a fixed count, on +the order of seven accounts. Beyond that ceiling the padding saturates and the +number of private accounts a transaction touches stops being hidden, which +weakens the privacy posture this RFP is built on. -### Resolved dependencies +This is a hard constraint on account layout, and it binds sooner than proposers +expect. A vault, a policy account, a proposal account, a spending-limit +accumulator, and a transfer recipient already approach the ceiling before any +per-member state exists. Designs that allocate an account per member (see F.8) +will exceed it. -#### Cross-program execution +Proposers must state the maximum number of private accounts any single operation +touches, and design the account layout to stay within the ceiling. -Execution of an arbitrary LEZ program (Functionality requirement F.3) relies on -the LEZ runtime's cross-program execution support, which is delivered as part -of the core runtime. Proposers should confirm its mechanism and constraints on -devnet. +#### Time: no clock is readable from the private path + +Three requirements depend on time: proposal expiry (F.2), the time lock (F.7), +and spending limits if the limit is per-period (F.8). LEZ offers no clock that a +program can read from the private path. + +Clock accounts exist, but they are **public** accounts. Taking one as a +pre-state in a privacy-preserving transaction puts a public account in the +transaction, which defeats the private posture and is a strong deanonymisation +signal, since every private transaction reading the clock reads the same +account. + +The mechanism that does work is the **timestamp validity window**: a program +declares that its output is valid only within a stated time range, and the state +machine rejects the transaction outside that range. This constrains the +transaction rather than letting the program read the current time. It is +sufficient for a time lock, because an unlock time known at proof-construction +time can be expressed as a window that opens at the unlock point, and the chain +rejects anything proved for an earlier window. + +Proposers must design F.2, F.7, and F.8 around validity windows and durable +program state. A team that goes looking for a clock API will not find a usable +one. + +#### Logos chat module + +The per-multisig coordination room (Functionality requirement F.9) depends on +the Logos chat module. The module is **not part of the LEZ repository**, so its +availability, SDK surface, and support for machine-readable payloads cannot be +confirmed from the LEZ codebase. Proposers must confirm all of this against the +module's own documentation and maintainers before relying on it. Alongside the +in-guest verifier, this is the largest external dependency risk in this RFP. ### Risks +#### In-guest signature verification is unbuilt + +Requirement F.2 has the program verify collected member approvals at execution. +**No primitive for this exists today.** Guest programs depend on `lee_core` and +`risc0-zkvm` only, and `lee_core` carries no elliptic-curve library; there is no +signature-verification code reachable from guest code anywhere in the LEZ tree. +The BIP-340/secp256k1 verifier that does exist is host-side, outside the zkVM, +and verifies the transaction witness set rather than program-level semantics. +The only cryptography available in-guest is SHA-256, plus ML-KEM and ChaCha20 +for the encryption path. + +This is proposer scope rather than a platform blocker: a `no_std` verifier must +be vendored into the guest, paying the RISC Zero cycle cost for M verifications +inside the proof. That is feasible in principle, but there is no precedent in +the repository to size it against, and the cost scales with M. It is the largest +unpriced item in this RFP, and Performance requirement P.2 makes the benchmark a +deliverable. + +Because the cost is unknown, proposers are encouraged to establish it early and +to consider whether in-guest signature verification is required at all. An +approval scheme built on the SHA-256 already available in-guest may satisfy +Reliability requirement R.1 far more cheaply; see Decisions for Review. + +This gap is not specific to multisig. Any program needing to verify +authorisation in its own execution will meet it, so a verifier built here has +value beyond this RFP. Proposers should design it as a reusable component rather +than a private detail of the multisig program. + #### Private-transaction throughput -Running over private accounts, each on-chain operation produces a proof and -consumes a private-transaction slot. LEZ private-transaction throughput per -block is limited (as of 2026-04, one private transaction per block on the -reference deployment). Carrying approvals through the coordination room removes -per-approval on-chain writes, so the on-chain footprint stays small (creation, -executions, configuration changes), but it remains bounded by this throughput. -Performance requirement P.2 requires this to be measured and reported. +Running over private accounts, each on-chain operation produces a Risc0 receipt +and consumes block capacity. The reference sequencer configuration bounds a +block at 20 transactions and 1 MiB, with no separate limit for private +transactions. The block-size bound is the one that binds: a real-proving +privacy-preserving transaction measures roughly 220 KiB on the wire, so +**approximately four private transactions fit in a block** and the +20-transaction count is never reached. At the reference 10-second block cadence +that is on the order of **0.4 private transactions per second for the entire +zone**, shared with every other application running on it. + +Proving cost is the more severe constraint, and it is paid client-side at +submission rather than by the sequencer. Published LEZ benchmarks put a single +privacy-preserving transaction at roughly **two minutes of proving on a +commodity laptop CPU**, with each chained call adding roughly a further minute. +A multisig execution that chains into a target program should therefore be +expected to cost several minutes of local proving. This shapes the product: the +mini-app and CLI must treat execution as a long-running background operation +with visible progress, not a request-response interaction. + +Carrying approvals through the coordination room removes per-approval on-chain +writes, so the on-chain footprint stays small (creation, executions, +configuration changes). Performance requirement P.1 requires these figures to be +re-measured on the target deployment and reported, since they will have moved. + +Note that proving cost scales with power-of-two-bucketed total cycles, not raw +cycle count: reducing cycles lowers cost only when it crosses a bucket boundary. +Benchmarks under Performance requirement P.2 must therefore be reported as a +step function rather than a linear fit. + +#### Development mode hides the real cost + +LEZ supports a development mode that skips real proving. It is the right way to +run most tests, but it produces stub receipts orders of magnitude smaller and +faster than real ones. A team that develops and benchmarks exclusively in +development mode will carry figures roughly two orders of magnitude optimistic +and discover the true cost only at integration, when the account layout and +approval scheme are already fixed. + +Proposers should establish real-proving measurements early, before the design is +committed, and Performance requirement P.1 makes real-proving benchmarks a +condition of acceptance. #### Signing-layer trust -The Bybit and WazirX losses were not smart-contract failures; they exploited -the gap between what a signer saw in a UI and what they actually authorised. -Usability requirement U.6 (show the exact decoded action before signing) is the -primary mitigation and must not be treated as optional polish. +The Bybit and WazirX losses were not smart-contract failures; they exploited the +gap between what a signer saw in a UI and what they actually authorised. The +primary mitigation is the Logos module model: the UI is installed and verified +once, not downloaded from a remote server on every use. Usability requirement +U.6 (show the exact decoded action before signing) is a secondary mitigation and +must not be treated as optional polish. ## 👤 Recommended Team Profile @@ -352,11 +601,23 @@ Team experienced with: ## ⏱ Timeline Expectations -Estimated duration: **12 weeks** (fresh implementation of the M-of-N program +Estimated duration: **6 months** (fresh implementation of the M-of-N program with its private-by-default execution path, the coordination room with in-room -approval collection, and the SDK, CLI, and mini-app). The privacy posture and -the coordination channel are settled (see below); the remaining open decision -affects the vault design and sits within this estimate. +approval collection, and the SDK, CLI, and mini-app). The vault architecture and +privacy posture are settled; vault key custody and the approval-verification +scheme are left to the proposer (see Decisions for Review). + +This estimate assumes a team already productive on LEZ. Proposers new to the +platform should account for ramp-up separately and say so. + +**A phased proposal is welcome.** The in-guest approval verifier is on the +critical path, has no precedent to size against, and its cost determines the +largest workable M. Proposers may structure the work so that an initial phase +establishes the approval-verification benchmark (P.2), the account layout +against the private-account ceiling, and the time-lock design, with the scope +and cost of the remainder fixed once those are known. A proposal that names this +uncertainty and structures around it will be viewed more favourably than one +that prices it silently. ## 🌍 Open Source Requirement @@ -367,52 +628,99 @@ All code must be released under the **MIT+Apache2.0 dual License**. - [Logos Documentation](https://github.com/logos-co/logos-docs) - [logos-co/lez-multisig](https://github.com/logos-co/lez-multisig): a public multisig proof-of-concept sample app on LEZ; prior art only — this RFP - commissions a fresh design and implementation + commissions a fresh design and implementation. Note that its architecture is + incompatible with private accounts: it requires member accounts to be fresh + zero-nonce keypairs claimed by the multisig program, which private accounts + cannot satisfy because they are owned by the privacy protocol and increment + the nonce on every use. Treat it as a reference for the public path only. +- **LP-0002, Private M-of-N Multisig** (open λ prize): commissions a private + M-of-N primitive for LEZ using anonymous threshold proofs, where the verifier + confirms a threshold was met without recording which members approved. It + overlaps this RFP's ground but is unclaimed, and its anonymity model differs + from Reliability requirement R.1 here, which requires approvals attributable + to current members. A proposer should read it for the design space it maps — + threshold proof schemes, nullifier design, and the LEZ nonce constraint — not + as a component this RFP builds on. - [Introduction to the Logos Execution Zone](https://docs.logos.co/lez): the public/private account model this RFP relies on +- [Logos Chat Module](https://docs.logos.co/messaging/chat-module/build-logos-module-that-uses-chat-module-api): + documentation for building modules that use the chat module API +- [LEZ Private Shared Pool Research](https://github.com/marclawclaw/research-multisig-sovereign/blob/master/lez-private-shared-pool.md): + research on shared private accounts and their properties for multisig vaults +- [Journey: Allow different users to interact with same private account](https://github.com/logos-co/logos-docs/issues/321): + official Logos journey documenting the GMS-based shared private account + feature. Note that its stated release status is out of date: the feature is + bundled in the released `v0.2.0` tag (2026-06-30), not only on `main`. Take + care with the tag list — `v0.3.0` predates this work and is not a newer + release. + +Account derivation constants are versioned and have changed between LEZ +releases; public and private PDA derivations do not currently share a version +prefix. Any change to these constants changes every derived account address. +Proposers should pin the derivation they build against with their own tests +rather than assuming stability across releases. ## 🧩 Decisions for Review -Two decisions that shaped earlier drafts are now settled and embedded in the -requirements above: the privacy posture is **private by default**, with the -auditability and transparency options listed in Privacy Architecture; and -**approvals flow through the E2EE coordination room**, with the program -verifying the collected approvals at execution (no per-approval on-chain -writes). One decision remains open. - -### Decision — M-of-N enforcement for the private vault - -A private multisig needs somewhere to hold value and somewhere to enforce the -quorum, and LEZ's shared-private-account mechanism constrains both. What is -known today: a LEZ private account can be shared through a single group secret -from which every member derives full spending and viewing authority — -effectively N-of-N, not M-of-N; the chain cannot distinguish a group-owned -account from a single-owner one; and there is no revocation short of migrating -funds to a fresh account. A genuine M-of-N must therefore be enforced somewhere -other than the group secret itself. - -- **Option A — Program-enforced M-of-N over a program-derived private - account.** The vault is a private account controlled by the multisig program; - the M-of-N check runs inside the program's verified execution, and members - hold no independent spending authority over the vault. The group-secret - mechanism is not used for spending. Strongest enforcement, and member changes - are program state changes rather than key migrations; depends on - program-derived private accounts being supported on LEZ. -- **Option B — Group-shared account as vault, M-of-N enforced in the approval - layer.** The vault is a group-shared private account and the multisig gates - which spends are authorised through its approval flow. Simpler account and - key-distribution story, but every group member cryptographically retains full - spending authority, so enforcement is procedural rather than cryptographic, - and excluding a member requires migrating the vault. -- **Option C — Group-shared account as vault, with threshold cryptography over - the group-derived keys** (for example a FROST-style scheme), giving - cryptographic M-of-N at the key layer. Strongest key-layer enforcement, but - immature tooling; threshold-signature implementation is out of scope for this - RFP, so this would be a documented future extension rather than a - deliverable. - -The proposer should state which baseline their design assumes; the choice will -be settled at contracting time. +Settled and embedded in the requirements above: + +1. The privacy posture is **private by default**, with the auditability and + transparency options listed in Privacy Architecture. +2. **Approvals flow through the E2EE coordination room**, with the program + verifying the collected approvals at execution (no per-approval on-chain + writes). +3. The vault is a **private PDA derived under the multisig program's ID**, with + M-of-N enforced by the program's verified execution, backed by the + `program_owner` ownership latch described in Platform Dependencies. Member + changes are program state changes, not key migrations. + +Group-shared accounts derived from a Group Master Secret are **not** the vault +mechanism. The GMS distributes full spending authority to every holder, so a +vault built on it would be advisory rather than enforcing. The GMS remains +useful for shared **viewing** of vault activity and for keying the coordination +room, and proposers may use it for those purposes. + +### Open for the proposer to decide + +**Vault key custody.** Someone must hold the vault's nsk to construct a spend +proof. Neither model below is unambiguously better, and the choice determines +which other requirements can be honoured in full. The proposer must choose one, +justify it, and document the resulting threat model: + +- **All members hold the vault nsk.** Any member can construct a spend + transaction, but the program rejects it below quorum, so funds are safe once + the vault is initialised. No liveness dependency, no single point of key loss, + and no trusted coordinator. The costs: "execute" is not a separable role under + F.6, because every member holds the key needed to submit; members can grief + each other by racing spends and burning proving effort; and the + pre-initialisation window described in Platform Dependencies is a real + exposure that the design must close. +- **A designated operator or relayer holds the vault nsk.** Members hold + approval keys only and cannot construct a spend transaction at all, which + makes F.6 role separation fully meaningful and removes the griefing vector. + The cost is a trusted coordinator: a liveness dependency, a single point of + key loss, and a censorship vector. Choosing this model forfeits the + no-trusted-coordinator property claimed in Why This Matters, and the + documentation must say so plainly rather than implying it still holds. + +Neither model provides cryptographic k-of-N at the key layer. That requires +threshold cryptography, noted below as a future extension. + +**Approval verification scheme.** Which signature scheme is verified in-guest, +and which `no_std` implementation is vendored, is the proposer's choice, subject +to the benchmark required by Performance requirement P.2. Proposers should also +consider whether in-guest signature verification is needed at all: committing to +an approval set by hash in the program's account data, using the SHA-256 already +available in-guest, may satisfy Reliability requirement R.1 at a fraction of the +proving cost. A proposal that argues for this and shows it meets R.1 is welcome. + +### Future extension (not a deliverable) + +**Threshold cryptography over the vault keys** (for example a FROST-style +scheme) would give cryptographic M-of-N at the key layer, removing the need for +any single party to hold a complete spending key. Tooling is immature and +threshold-signature implementation is out of scope for this RFP; a proposer may +document it as a migration path. ## ✏️ How to Apply From 9ef25fff9e4ebe4330d10ab07d2e59b84dde1ceb Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 14:05:42 +1000 Subject: [PATCH 05/14] RFP-005: address PR #113 review Strip implementation detail from the requirements, keeping them to what is needed rather than how to achieve it. F.3 restored to "any arbitrary program", F.7 and F.8 to the bare requirement, and the mechanism prose removed from F.2, F.4, F.6, R.2 and P.2. Express auditability per use case: a corporate treasury needs a narrow audience, a DAO a wider one, and members joining later need current evidence rather than a setup-time claim. Added ongoing assurance as a requirement and left the disclosure mechanism to the implementer. U.2 is a QML mini-app without forcing a C++ backend. Removed the marclawclaw research reference; it is a data dump rather than a citable source. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 124 ++++++---------------- 1 file changed, 35 insertions(+), 89 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index fb76b708..ad5e03a7 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -69,58 +69,26 @@ the vehicle for delivering that. member publishes a proposal to the room; members approve or reject asynchronously; once M approvals are collected the action can be executed, and the program verifies the collected approvals at execution. Proposals - carry an expiry after which the program rejects execution. Verifying - approvals inside the program requires vendoring a signature verifier into - the guest environment, which has no such primitive today; see Platform - Dependencies. -03. Execute approved actions against other programs deployed in the given LEZ, - via chained calls. Note two platform constraints: every callee must be - declared as a dependency at proof-construction time with its program binary - available to the prover, and a transaction is capped at a small number of - chained calls in total (not nesting depth). "Arbitrary" therefore means any - statically known call graph, not any call graph discovered at execution - time. Proposers must state how a proposal's target set is declared and - verified against these limits. + carry an expiry after which the program rejects execution. +03. Execute approved actions on any arbitrary program deployed in the given LEZ. 04. Provide a registry for proposal code and target programs so any client can confirm what instructions a proposal's bytes represent and what program they - invoke, without relying on a single trusted source. "Without relying on a - single trusted source" means the mapping must be independently verifiable by - any client, for example by content-addressing entries so a client checks the - binding itself rather than trusting the publisher. Building a decentralised - governance layer for registry membership is out of scope. Note that - Usability requirement U.6 (decode the action before signing) can only be as - complete as this registry's coverage; proposers must state what a client - displays when a target program is not registered. + invoke, without relying on a single trusted source. Note that Usability + requirement U.6 (decode the action before signing) can only be as complete + as this registry's coverage; proposers must state what a client displays + when a target program is not registered. 05. Support configuration changes (add or remove a member, change the threshold) through the same M-of-N approval flow, so structural changes cannot bypass the quorum. -06. Support role separation among members so that the ability to propose and the - ability to approve can be assigned independently. At minimum, a proposing - key need not be an approving key. Note that "execute" is separable only - under the operator custody model: where every member holds the vault - spending key, any member can submit a transaction, and the program can only - decline to count them as an approver. Documentation must state which - guarantee the chosen custody model actually delivers, rather than implying - execution is gated when it is not. +06. Support role separation among members so that the ability to propose, to + approve, and to execute can be assigned independently. At minimum, a + proposing key need not be an approving key. Documentation must state which + guarantee the chosen vault custody model actually delivers for each role. 07. Support an optional per-multisig time lock: a configurable delay between an - action reaching quorum and becoming executable. A time lock of zero means - immediate execution. Because no clock is readable from the private path (see - Platform Dependencies), this must be enforced through timestamp validity - windows and durable program state, and the proposer must document the - resulting security properties, including what a prover can and cannot - influence about the effective unlock time. + action reaching quorum and becoming executable, enforced by the program. A + time lock of zero means immediate execution. 08. Support an optional spending-limit policy: a member or sub-quorum may execute transfers up to a configured limit without the full M-of-N approval. - This requirement deliberately weakens the vault's security below the limit, - and it compounds with custody: where every member holds the vault spending - key, the limit accounting in the program is the only control standing - between a single member and the funds. Per-period limits additionally - require a time source the private path does not provide, and per-member - accumulators consume private-account slots against the padding ceiling - described in Platform Dependencies. Proposers must justify the account - layout and state the residual risk. Implementing this as a fixed lifetime - allowance rather than a renewing per-period limit is acceptable and avoids - the time dependency. 09. Provision an end-to-end-encrypted coordination room per multisig using the Logos chat module, scoped to the multisig's members. The room carries both human deliberation and machine coordination: proposals are published to the @@ -139,10 +107,9 @@ the vehicle for delivering that. 1. Provide an SDK that can be used to build Logos modules for interacting with the multisig (create, propose, approve, reject, execute, manage members and policies). -2. Provide a Logos mini-app GUI, built as QML with a C++ backend module, with - local build instructions, downloadable assets, and loadable in Logos app - (Basecamp) via git repo. The mini-app must surface the per-multisig - coordination room alongside the proposal list. +2. Provide a Logos mini-app QML GUI with local build instructions, downloadable + assets, and loadable in Logos app (Basecamp) via git repo. The mini-app must + surface the per-multisig coordination room alongside the proposal list. 3. Provide a CLI that uses the Logos core headless framework and covers core functionality of the program (create, propose, approve, reject, execute, and configuration changes). The CLI may have fewer features than the GUI mini-app @@ -170,7 +137,6 @@ the vehicle for delivering that. distinct valid approvals from current members on exactly the action being executed; no approval is double-counted or replayed across proposals, and an action cannot execute with fewer than M valid approvals. - 2. A configuration change (member set or threshold) must invalidate approval sets gathered under the old configuration: an approval collected before the change must not count toward quorum after it, unless the action had already @@ -179,15 +145,6 @@ the vehicle for delivering that. cutoff, and what happens to a pending action when a member is removed during a time-lock delay. - The private account nonce cannot carry this binding. The circuit overwrites - it on every private update with a value derived from the account's spending - key, so it is an opaque hash chain rather than a readable counter: the - program cannot read a meaningful sequence number from it, cannot predict the - post-state value, and every spending-key holder can compute the entire future - chain. Replay and configuration binding must therefore be carried in the - program's own account data, for example a configuration epoch that increments - on every change and that every approval commits to. - #### Performance 1. Compute unit usage, transaction size, and client-side proving time for each @@ -196,16 +153,12 @@ the vehicle for delivering that. mode produces stub receipts orders of magnitude smaller and faster than real ones, and figures gathered that way are meaningless for capacity planning; benchmarks submitted from development mode will not be accepted. -2. The RISC Zero cycle cost of in-guest approval verification must be - benchmarked and reported as a function of M, since no signature-verification - primitive exists in the guest environment today and the vendored - implementation is on the critical path for proof size and cost. Report the - largest M that remains viable within block limits, presented as a step - function (see Platform Dependencies on power-of-two cycle bucketing). **M of - at least 5 must remain viable** for the deliverable to be considered - complete; if the benchmark shows otherwise, the finding itself is a - reportable result and triggers a scope discussion rather than silent delivery - of a lower ceiling. +2. The cost of verifying approvals at execution must be benchmarked and reported + as a function of M, since it is on the critical path for proof size and cost. + Report the largest M that remains viable within block limits. **M of at least + 5 must remain viable** for the deliverable to be considered complete; if the + benchmark shows otherwise, the finding itself is a reportable result and + triggers a scope discussion rather than silent delivery of a lower ceiling. #### Supportability @@ -275,12 +228,6 @@ pending-proposal metadata off-chain even for a public-posture multisig. An on-chain proposal record is not an audit-trail advantage over this model: both models yield a verifiable record of who authorised an action at execution. -The room is coordination, not enforcement: quorum is always verified and -enforced by the program at execution, never by the chat channel. Because there -is no live on-chain pending view, the client must reliably gather, retain, and -present room state so signers always see the current proposal set and collected -approvals. - Room membership and program membership are separate state and can diverge. Removing a member through the M-of-N flow (F.5) changes the program's member set, but does not by itself evict that member from the coordination room, and a @@ -308,26 +255,27 @@ multisig, not concealment of the user. **Auditability and transparency options.** Privacy is not the opposite of oversight, and different organisations need different audiences able to inspect -the multisig. The program must support: +the multisig. A corporate or organisational treasury typically needs a narrow +audience (auditors, a board) able to inspect it. A DAO treasury typically needs +a wider one: members joining a DAO may reasonably require evidence that the +treasury is secured as its key holders claim, on an ongoing basis rather than +once at setup. The program must support: 1. **Public posture (operator-selectable).** At creation the operator may deploy the multisig fully public instead of private, for treasuries that want anyone to be able to inspect configuration, holdings, and activity at all times. - 2. **Selective disclosure to a defined audience.** The program must enable a private multisig to disclose its state (configuration, holdings, activity) to a chosen audience without making that information public and without granting - spending power to that audience. - - The platform primitive for this is viewing-key sharing, and it is - all-or-nothing. A private account's note is a single encrypted blob covering - the whole account state, so sharing the viewing key reveals every field of - every note for that account, for all time, past and future. Disclosing the - threshold but not the balance, or 2026 activity but not 2025, is not - expressible by sharing keys alone. Anything finer must be constructed in the - program's account layout, for example by separating disclosable state into a - distinct account with its own viewing key. Proposers must state which - granularity they deliver and what an audience unavoidably learns. + spending power to that audience. The audience may be narrow (a named auditor) + or wide (all members of a DAO), and the mechanism must support both. The + implementer should study and propose the mechanism that best balances + auditability, security, and usability, and must state which granularity it + delivers and what an audience unavoidably learns. +3. **Ongoing assurance.** The program must enable a multisig to demonstrate its + holdings and configuration to its audience repeatedly over time, so that a + party joining later can obtain current evidence rather than relying on a + claim made at setup. Documentation (Usability requirement U.5) must state the resulting public/private split explicitly for the configured posture, including who can @@ -645,8 +593,6 @@ All code must be released under the **MIT+Apache2.0 dual License**. public/private account model this RFP relies on - [Logos Chat Module](https://docs.logos.co/messaging/chat-module/build-logos-module-that-uses-chat-module-api): documentation for building modules that use the chat module API -- [LEZ Private Shared Pool Research](https://github.com/marclawclaw/research-multisig-sovereign/blob/master/lez-private-shared-pool.md): - research on shared private accounts and their properties for multisig vaults - [Journey: Allow different users to interact with same private account](https://github.com/logos-co/logos-docs/issues/321): official Logos journey documenting the GMS-based shared private account feature. Note that its stated release status is out of date: the feature is From 8d9e851e4d46df2207dcdbbbcf9c2d253e8876a0 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 14:08:04 +1000 Subject: [PATCH 06/14] RFP-005: correct the signing-layer primary mitigation U.6 claimed to be the primary mitigation for the signing-layer attack surface, contradicting the Risks section, which correctly names the Logos module model: the UI is installed and verified once rather than fetched from a remote server on every use. U.6 is a complement to that, not a replacement. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index ad5e03a7..880b1dab 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -125,9 +125,11 @@ the vehicle for delivering that. 6. Before a member signs an approval, the mini-app must display the exact action that approval authorises (target program, decoded instruction, amounts), so the member verifies what they are signing rather than a UI-rendered summary. - This is the primary mitigation for the signing-layer attack surface behind - the Bybit and WazirX losses: in both incidents, signers authorised what a - compromised UI showed them, not what was actually executed. + This addresses the signing-layer attack surface behind the Bybit and WazirX + losses, in which signers authorised what a compromised UI showed them rather + than what was actually executed. It complements the primary mitigation, which + is the Logos module model itself: the UI is installed and verified once + rather than fetched from a remote server on every use. 7. Failed or rejected proposals and executions must return clear, actionable error messages. From 6e6a5a85c00d85587ca40167e8b537a9f1064f27 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 14:13:27 +1000 Subject: [PATCH 07/14] RFP-005: reduce Platform Dependencies to platform commitments The section had grown into a description of how LEZ works internally, which does not belong in an RFP. Reduced from 256 lines to a short list of the platform components a proposer must build on. State the components rather than their mechanics: LEZ private accounts, shared private accounts, the Logos chat module, and testnet compatibility. Using the chat module for the coordination room is now explicitly mandatory, and compatibility with Logos testnet 0.3 and 0.4 is stated here and in Supportability. Highlight the shared private account feature as something proposers must study and account for, noting only that it distributes custody rather than dividing it, without describing the derivation. Removed the corresponding internals from Decisions and Resources so the document no longer refers to mechanisms it no longer explains. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 355 +++++----------------- 1 file changed, 69 insertions(+), 286 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 880b1dab..3db0c3f1 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -164,17 +164,17 @@ the vehicle for delivering that. #### Supportability -1. The multisig program is deployed and tested on LEZ devnet/testnet. +1. The multisig program is deployed and tested on LEZ devnet/testnet, and is + compatible with Logos testnet 0.3 and 0.4. 2. End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI. 3. CI must be green on the default branch. 4. Every hard requirement in Functionality, Usability, and Reliability has at least one corresponding test. At minimum this includes: an action cannot execute below threshold; a configuration change respects requirement R.2; and - a vault cannot be drained through the pre-initialisation window described in - Platform Dependencies. Performance requirements are satisfied by reported - measurements rather than pass/fail tests, but the benchmark harness must be - committed and reproducible. + a vault cannot be drained before it is fully initialised. Performance + requirements are satisfied by reported measurements rather than pass/fail + tests, but the benchmark harness must be committed and reproducible. 5. A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for creating a multisig, proposing, approving, and executing via CLI and front-end, including how the coordination room is @@ -286,249 +286,52 @@ see what under each disclosure mechanism. ## ⚠ Platform Dependencies This RFP is open for proposals. Proposers may begin design and development work, -but a working on-chain deployment depends on the primitives below. - -### Hard blockers - -#### Private-account execution (core LEE feature) - -The private-by-default posture requires running the multisig over LEE private -accounts: post-state commitments, nullifiers, and Risc0 validity proofs. These -are core LEE features, and the private-PDA lifecycle this RFP depends on is -covered by integration tests on LEZ `main`, for a single keyholder. Proposers -should confirm the state of private-account support on LEZ devnet against the -Resources below before relying on it. - -No end-to-end multi-party authorization flow exists in the LEZ repository today. -The primitives are present and the single-keyholder private-PDA lifecycle is -tested, but nothing demonstrates M-of-N in the program layer. This RFP -commissions the first such implementation. LP-0002 is an open prize covering -adjacent ground, but it is unclaimed and its design differs from this RFP's; see -Resources. - -#### Program-derived private PDAs (the enforcement mechanism) - -The vault is a private PDA derived under the multisig program's ID. This is what -makes M-of-N enforceable, and the mechanism has two parts, both present and -exercised on LEZ `main`: - -1. **Address binding.** A private PDA's account ID commits to the program: - `AccountId::for_private_pda(program_id, seed, npk, vpk, identifier)`. The - privacy-preserving circuit refuses any private-PDA pre-state whose npk has - not been proven to derive that account ID. Three binding paths exist: the - program's own `Claim::Pda(seed)`, a caller's `pda_seeds`, and an external - seed supplied directly as a circuit input. The third is what makes funding a - program-owned private PDA from another program possible, and proposers will - need it for vault funding. -2. **Ownership latch.** `validate_execution` permits a balance decrease only - when `account_program_owner == executing_program_id`. Once the vault's - `program_owner` is set to the multisig program, that latch is one-way: - ownership cannot be changed or reverted. Only the multisig program's verified - execution can move funds out. - -Enforcement therefore comes from the ownership latch, not from anything about -the key layer. A multisig program that asserts its M-of-N condition makes the -proof unconstructible when the condition fails. - -**The vault cannot be claimed by another program.** Because the account ID -commits to the program ID, and the claim path asserts that the account ID -re-derives from the *executing* program's own ID, a hostile program can only -claim accounts within its own namespace. Claiming the multisig's vault would -require a hash preimage collision. This is worth stating explicitly because the -circuit does not enforce authorization claims on private accounts generally: for -the private non-PDA path, `Claim::Authorized` is a deliberate no-op -("unauthorized private claiming is intentionally allowed"). That no-op does not -apply to the private-PDA claim path, which is address-bound. - -**What the circuit does not do.** It does not verify that a program's approval -predicate ran and returned true. It proves derivation-from-program plus the -seed/npk binding. The approval logic itself is the program's responsibility, and -the ownership latch is what forces the program to run at all. - -**Initialisation is security-critical.** The latch protects the vault only once -the multisig program has claimed it. An account that has been funded but not yet -claimed sits under the default program owner, where the balance-decrease rule -does not yet bind it to the multisig program, and any holder of the vault -spending key can move funds out before the program is ever involved. Vault -creation and first funding must therefore be atomic, or the design must make -pre-initialisation deposits impossible. Proposers must state how they achieve -this, and Reliability testing must cover it. - -**Vault key custody is an open design choice.** The circuit has no notion of an -npk that nobody holds: someone must hold the vault's nullifier secret key (nsk) -to construct the spend proof. Two models are viable and the proposer must choose -one and justify it (see Decisions for Review). - -#### Shared private accounts and group keys (not a multisig primitive) - -LEZ supports group-owned shared private accounts derived from a single 32-byte -Group Master Secret (GMS): every member independently derives the same account -keys (NSK/VSK/NPK/VPK). New members are admitted by sealing the GMS to their -public key and having them unseal it. - -**The GMS confers full spending authority and cannot be restricted to viewing.** -Because the derivation hands every holder the full nsk, and holding the nsk is -what permits a spend, distributing the GMS to N members distributes N copies of -full spending authority. It is not a multisig primitive and must not be used as -one. Where a view-only auditor is wanted, share the account's viewing key -instead — that is the mechanism that actually separates viewing from spending. - -Specifically, a **regular** (non-PDA) GMS-derived shared account carries no -program binding at all: its account ID is derived without a program ID, and its -`program_owner` ends up as the standard funding program. Any single GMS holder -can spend it directly without the multisig program ever being invoked. A -multisig built on that account shape would be advisory, not enforcing. - -Properties proposers should account for: - -- The key layer is effectively **1-of-N**: any GMS holder derives full spending - and viewing authority. There is no view-only or threshold share of the GMS. -- The GMS is a **root** secret. A holder derives keys for every account the - group creates under it, including accounts created after they joined, and can - re-seal the GMS to an arbitrary third party without the other members' - consent. -- Group membership is **not recorded anywhere** — not on-chain, and not in any - registry or distribution service. `invite` prints a sealed blob and `join` - accepts one; conveying it is entirely the operator's problem, and each - member's roster is independent local state that can silently diverge. -- There is **no member revocation**. Removing a member deletes only the caller's - own local copy; the removed member's GMS still derives working spending keys. - In-place GMS rotation is structurally impossible, because the account ID - commits to the derived npk and vpk — a new GMS is a different account. - Migration to a fresh GMS is the only path, it is not automated, and during the - sweep the removed member holds equal spending authority over the funds being - moved. They also retain permanent viewing access to the old account's history. - -The auditability options rely on LEE key separation: a private account has a -spending (nullifier) key and a viewing key, and sharing the viewing key yields a -view-only auditor. Note that the GMS itself cannot express this separation — any -GMS holder gets both. - -Proposers should confirm these properties against the LEZ codebase before -relying on them. - -#### Private-account count is part of the anonymity set - -A privacy-preserving transaction pads its private inputs to a fixed count, on -the order of seven accounts. Beyond that ceiling the padding saturates and the -number of private accounts a transaction touches stops being hidden, which -weakens the privacy posture this RFP is built on. - -This is a hard constraint on account layout, and it binds sooner than proposers -expect. A vault, a policy account, a proposal account, a spending-limit -accumulator, and a transfer recipient already approach the ceiling before any -per-member state exists. Designs that allocate an account per member (see F.8) -will exceed it. - -Proposers must state the maximum number of private accounts any single operation -touches, and design the account layout to stay within the ceiling. - -#### Time: no clock is readable from the private path - -Three requirements depend on time: proposal expiry (F.2), the time lock (F.7), -and spending limits if the limit is per-period (F.8). LEZ offers no clock that a -program can read from the private path. - -Clock accounts exist, but they are **public** accounts. Taking one as a -pre-state in a privacy-preserving transaction puts a public account in the -transaction, which defeats the private posture and is a strong deanonymisation -signal, since every private transaction reading the clock reads the same -account. - -The mechanism that does work is the **timestamp validity window**: a program -declares that its output is valid only within a stated time range, and the state -machine rejects the transaction outside that range. This constrains the -transaction rather than letting the program read the current time. It is -sufficient for a time lock, because an unlock time known at proof-construction -time can be expressed as a window that opens at the unlock point, and the chain -rejects anything proved for an earlier window. - -Proposers must design F.2, F.7, and F.8 around validity windows and durable -program state. A team that goes looking for a clock API will not find a usable -one. - -#### Logos chat module - -The per-multisig coordination room (Functionality requirement F.9) depends on -the Logos chat module. The module is **not part of the LEZ repository**, so its -availability, SDK surface, and support for machine-readable payloads cannot be -confirmed from the LEZ codebase. Proposers must confirm all of this against the -module's own documentation and maintainers before relying on it. Alongside the -in-guest verifier, this is the largest external dependency risk in this RFP. +but a working on-chain deployment depends on the platform components below. +Proposers should confirm the current state of each against the Resources section +before relying on it. + +- **LEZ private accounts.** The private-by-default posture requires running the + multisig over LEZ private accounts. Note that no end-to-end multi-party + authorisation flow exists on LEZ today: the underlying primitives are + available, but this RFP commissions the first such implementation. + +- **Shared private accounts.** LEZ provides group-owned shared private accounts + derived from a single Group Master Secret, documented in the Journey linked + under Resources. Proposers should study this feature and state how, and + whether, they use it. Note that every holder of the group secret derives full + spending authority over the shared account, so it distributes custody rather + than dividing it; understanding its properties is a prerequisite to designing + the vault. + +- **Logos chat module.** The per-multisig coordination room (F.9) must be built + on the Logos chat module. This is mandatory, not a suggested option. + +- **Logos testnet compatibility.** The delivered implementation must be + compatible with Logos testnet 0.3 and 0.4. ### Risks -#### In-guest signature verification is unbuilt - -Requirement F.2 has the program verify collected member approvals at execution. -**No primitive for this exists today.** Guest programs depend on `lee_core` and -`risc0-zkvm` only, and `lee_core` carries no elliptic-curve library; there is no -signature-verification code reachable from guest code anywhere in the LEZ tree. -The BIP-340/secp256k1 verifier that does exist is host-side, outside the zkVM, -and verifies the transaction witness set rather than program-level semantics. -The only cryptography available in-guest is SHA-256, plus ML-KEM and ChaCha20 -for the encryption path. - -This is proposer scope rather than a platform blocker: a `no_std` verifier must -be vendored into the guest, paying the RISC Zero cycle cost for M verifications -inside the proof. That is feasible in principle, but there is no precedent in -the repository to size it against, and the cost scales with M. It is the largest -unpriced item in this RFP, and Performance requirement P.2 makes the benchmark a -deliverable. - -Because the cost is unknown, proposers are encouraged to establish it early and -to consider whether in-guest signature verification is required at all. An -approval scheme built on the SHA-256 already available in-guest may satisfy -Reliability requirement R.1 far more cheaply; see Decisions for Review. - -This gap is not specific to multisig. Any program needing to verify -authorisation in its own execution will meet it, so a verifier built here has -value beyond this RFP. Proposers should design it as a reusable component rather -than a private detail of the multisig program. - -#### Private-transaction throughput - -Running over private accounts, each on-chain operation produces a Risc0 receipt -and consumes block capacity. The reference sequencer configuration bounds a -block at 20 transactions and 1 MiB, with no separate limit for private -transactions. The block-size bound is the one that binds: a real-proving -privacy-preserving transaction measures roughly 220 KiB on the wire, so -**approximately four private transactions fit in a block** and the -20-transaction count is never reached. At the reference 10-second block cadence -that is on the order of **0.4 private transactions per second for the entire -zone**, shared with every other application running on it. - -Proving cost is the more severe constraint, and it is paid client-side at -submission rather than by the sequencer. Published LEZ benchmarks put a single -privacy-preserving transaction at roughly **two minutes of proving on a -commodity laptop CPU**, with each chained call adding roughly a further minute. -A multisig execution that chains into a target program should therefore be -expected to cost several minutes of local proving. This shapes the product: the -mini-app and CLI must treat execution as a long-running background operation -with visible progress, not a request-response interaction. - -Carrying approvals through the coordination room removes per-approval on-chain -writes, so the on-chain footprint stays small (creation, executions, -configuration changes). Performance requirement P.1 requires these figures to be -re-measured on the target deployment and reported, since they will have moved. - -Note that proving cost scales with power-of-two-bucketed total cycles, not raw -cycle count: reducing cycles lowers cost only when it crosses a bucket boundary. -Benchmarks under Performance requirement P.2 must therefore be reported as a -step function rather than a linear fit. - -#### Development mode hides the real cost - -LEZ supports a development mode that skips real proving. It is the right way to -run most tests, but it produces stub receipts orders of magnitude smaller and -faster than real ones. A team that develops and benchmarks exclusively in -development mode will carry figures roughly two orders of magnitude optimistic -and discover the true cost only at integration, when the account layout and -approval scheme are already fixed. - -Proposers should establish real-proving measurements early, before the design is -committed, and Performance requirement P.1 makes real-proving benchmarks a -condition of acceptance. +#### Approval verification cost + +The program must verify collected member approvals inside its own execution. +There is no precedent on LEZ to size this against, and the cost scales with M, +so it is the largest unpriced item in this RFP. Proposers should establish this +cost early, before the design is committed. Performance requirement P.2 makes +the benchmark a deliverable. + +#### Private-transaction throughput and proving cost + +Private-transaction throughput per block is limited, and proof generation is +paid client-side and measured in minutes rather than seconds. This shapes the +product: the mini-app and CLI must treat execution as a long-running background +operation with visible progress, not a request-response interaction. Carrying +approvals through the coordination room keeps the on-chain footprint small, but +proposers must measure and report the real figures under Performance requirement +P.1. + +Benchmarks must be produced with real proving. Development mode skips proof +generation and yields figures that are orders of magnitude optimistic, which is +misleading for capacity planning. #### Signing-layer trust @@ -596,17 +399,7 @@ All code must be released under the **MIT+Apache2.0 dual License**. - [Logos Chat Module](https://docs.logos.co/messaging/chat-module/build-logos-module-that-uses-chat-module-api): documentation for building modules that use the chat module API - [Journey: Allow different users to interact with same private account](https://github.com/logos-co/logos-docs/issues/321): - official Logos journey documenting the GMS-based shared private account - feature. Note that its stated release status is out of date: the feature is - bundled in the released `v0.2.0` tag (2026-06-30), not only on `main`. Take - care with the tag list — `v0.3.0` predates this work and is not a newer - release. - -Account derivation constants are versioned and have changed between LEZ -releases; public and private PDA derivations do not currently share a version -prefix. Any change to these constants changes every derived account address. -Proposers should pin the derivation they build against with their own tests -rather than assuming stability across releases. + official Logos journey documenting the shared private account feature ## 🧩 Decisions for Review @@ -617,50 +410,40 @@ Settled and embedded in the requirements above: 2. **Approvals flow through the E2EE coordination room**, with the program verifying the collected approvals at execution (no per-approval on-chain writes). -3. The vault is a **private PDA derived under the multisig program's ID**, with - M-of-N enforced by the program's verified execution, backed by the - `program_owner` ownership latch described in Platform Dependencies. Member - changes are program state changes, not key migrations. +3. The vault is **controlled by the multisig program**, with M-of-N enforced by + the program's verified execution rather than by how the vault's keys are + distributed. Member changes are program state changes, not key migrations. Group-shared accounts derived from a Group Master Secret are **not** the vault -mechanism. The GMS distributes full spending authority to every holder, so a -vault built on it would be advisory rather than enforcing. The GMS remains +mechanism: every holder of the group secret gets full spending authority, so a +vault built on one would be advisory rather than enforcing. The feature remains useful for shared **viewing** of vault activity and for keying the coordination room, and proposers may use it for those purposes. ### Open for the proposer to decide -**Vault key custody.** Someone must hold the vault's nsk to construct a spend -proof. Neither model below is unambiguously better, and the choice determines -which other requirements can be honoured in full. The proposer must choose one, -justify it, and document the resulting threat model: +**Vault key custody.** A spend must ultimately be constructed by some party +holding the vault's spending key. Both models below are viable; the proposer +must choose one, justify it, and document the resulting threat model: -- **All members hold the vault nsk.** Any member can construct a spend +- **All members hold the vault spending key.** Any member can construct a spend transaction, but the program rejects it below quorum, so funds are safe once the vault is initialised. No liveness dependency, no single point of key loss, - and no trusted coordinator. The costs: "execute" is not a separable role under - F.6, because every member holds the key needed to submit; members can grief - each other by racing spends and burning proving effort; and the - pre-initialisation window described in Platform Dependencies is a real - exposure that the design must close. -- **A designated operator or relayer holds the vault nsk.** Members hold - approval keys only and cannot construct a spend transaction at all, which - makes F.6 role separation fully meaningful and removes the griefing vector. - The cost is a trusted coordinator: a liveness dependency, a single point of - key loss, and a censorship vector. Choosing this model forfeits the - no-trusted-coordinator property claimed in Why This Matters, and the - documentation must say so plainly rather than implying it still holds. + and no trusted coordinator. The cost is that "execute" is not a separable role + under F.6, since every member holds what is needed to submit. +- **A designated operator or relayer holds the vault spending key.** Members + hold approval keys only and cannot construct a spend transaction at all, which + makes F.6 role separation fully meaningful. The cost is a trusted coordinator: + a liveness dependency, a single point of key loss, and a censorship vector. + Choosing this model forfeits the no-trusted-coordinator property claimed in + Why This Matters, and the documentation must say so plainly. Neither model provides cryptographic k-of-N at the key layer. That requires threshold cryptography, noted below as a future extension. -**Approval verification scheme.** Which signature scheme is verified in-guest, -and which `no_std` implementation is vendored, is the proposer's choice, subject -to the benchmark required by Performance requirement P.2. Proposers should also -consider whether in-guest signature verification is needed at all: committing to -an approval set by hash in the program's account data, using the SHA-256 already -available in-guest, may satisfy Reliability requirement R.1 at a fraction of the -proving cost. A proposal that argues for this and shows it meets R.1 is welcome. +**Approval verification scheme.** How member approvals are verified inside the +program is the proposer's choice, subject to the benchmark required by +Performance requirement P.2 and to meeting Reliability requirement R.1. ### Future extension (not a deliverable) From 95e99f9bcee66bb93d61e00af88bded1759b850f Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 14:42:15 +1000 Subject: [PATCH 08/14] RFP-005: move platform mandates into Supportability The requirement to use LEZ, the Logos chat module, and to be compatible with Logos testnet 0.3 and 0.4 belongs in FURPS as testable supportability requirements, not in a prose section. Added as S.1 to S.3 and renumbered the rest. Platform Dependencies now carries only what is not a requirement: that no end-to-end multi-party authorisation flow exists on LEZ yet, and that shared private accounts are a feature proposers should study. Removed the Signing-layer trust risk. Its content is already covered by U.6 and the Overview. Also removed references orphaned by the deletion of Decisions for Review: the custody-model qualifier in Why This Matters, the pointer in Timeline Expectations, and the custody wording in F.6. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 173 ++++++---------------- 1 file changed, 49 insertions(+), 124 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 3db0c3f1..3a8d8ec6 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -49,10 +49,7 @@ session, at the cost of hardware immaturity and, for MuSig2, an n-of-n-only limitation. Every implementation that keeps the quorum on-chain is transparent. On LEZ, the same multisig program can run over private accounts, so the chain records only a commitment to the post-state and a validity proof, without giving -up k-of-n. Under the all-members key-custody model it achieves this without a -trusted coordinator; the alternative custody model trades that property away for -stricter role separation, and the choice is left to the proposer. This RFP is -the vehicle for delivering that. +up k-of-n. This RFP is the vehicle for delivering that. ## ✅ Scope of Work @@ -82,8 +79,8 @@ the vehicle for delivering that. the quorum. 06. Support role separation among members so that the ability to propose, to approve, and to execute can be assigned independently. At minimum, a - proposing key need not be an approving key. Documentation must state which - guarantee the chosen vault custody model actually delivers for each role. + proposing key need not be an approving key. Documentation must state what + guarantee the implementation delivers for each role. 07. Support an optional per-multisig time lock: a configurable delay between an action reaching quorum and becoming executable, enforced by the program. A time lock of zero means immediate execution. @@ -164,31 +161,34 @@ the vehicle for delivering that. #### Supportability -1. The multisig program is deployed and tested on LEZ devnet/testnet, and is - compatible with Logos testnet 0.3 and 0.4. -2. End-to-end integration tests run against a LEZ sequencer (standalone mode) - and are included in CI. -3. CI must be green on the default branch. -4. Every hard requirement in Functionality, Usability, and Reliability has at - least one corresponding test. At minimum this includes: an action cannot - execute below threshold; a configuration change respects requirement R.2; and - a vault cannot be drained before it is fully initialised. Performance - requirements are satisfied by reported measurements rather than pass/fail - tests, but the benchmark harness must be committed and reproducible. -5. A README documents end-to-end usage: deployment steps, program addresses, and - step-by-step instructions for creating a multisig, proposing, approving, and - executing via CLI and front-end, including how the coordination room is - provisioned. -6. Submit a - [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) - for the SDK, covering the developer integration journey. -7. Submit a - [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) - for the CLI, covering the core operator journey. -8. Provide Figma designs or equivalent for the mini-app GUI, including the - proposal list and the coordination room. -9. Publish resulting modules in the - [Logos modules catalog](https://github.com/logos-co/logos-modules-release-base). +01. The multisig program runs on the Logos Execution Zone (LEZ) and uses LEZ + private accounts for its private-by-default posture. +02. The per-multisig coordination room is built on the Logos chat module. +03. The delivered implementation is compatible with Logos testnet 0.3 and 0.4. +04. The multisig program is deployed and tested on LEZ devnet/testnet. +05. End-to-end integration tests run against a LEZ sequencer (standalone mode) + and are included in CI. +06. CI must be green on the default branch. +07. Every hard requirement in Functionality, Usability, and Reliability has at + least one corresponding test. At minimum this includes: an action cannot + execute below threshold; a configuration change respects requirement R.2; + and a vault cannot be drained before it is fully initialised. Performance + requirements are satisfied by reported measurements rather than pass/fail + tests, but the benchmark harness must be committed and reproducible. +08. A README documents end-to-end usage: deployment steps, program addresses, + and step-by-step instructions for creating a multisig, proposing, approving, + and executing via CLI and front-end, including how the coordination room is + provisioned. +09. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the SDK, covering the developer integration journey. +10. Submit a + [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) + for the CLI, covering the core operator journey. +11. Provide Figma designs or equivalent for the mini-app GUI, including the + proposal list and the coordination room. +12. Publish resulting modules in the + [Logos modules catalog](https://github.com/logos-co/logos-modules-release-base). ### Soft Requirements @@ -286,28 +286,16 @@ see what under each disclosure mechanism. ## ⚠ Platform Dependencies This RFP is open for proposals. Proposers may begin design and development work, -but a working on-chain deployment depends on the platform components below. -Proposers should confirm the current state of each against the Resources section -before relying on it. +but a working on-chain deployment depends on the Logos components named in the +Supportability requirements. Proposers should confirm the current state of each +against the Resources section before relying on it. -- **LEZ private accounts.** The private-by-default posture requires running the - multisig over LEZ private accounts. Note that no end-to-end multi-party - authorisation flow exists on LEZ today: the underlying primitives are - available, but this RFP commissions the first such implementation. - -- **Shared private accounts.** LEZ provides group-owned shared private accounts - derived from a single Group Master Secret, documented in the Journey linked - under Resources. Proposers should study this feature and state how, and - whether, they use it. Note that every holder of the group secret derives full - spending authority over the shared account, so it distributes custody rather - than dividing it; understanding its properties is a prerequisite to designing - the vault. - -- **Logos chat module.** The per-multisig coordination room (F.9) must be built - on the Logos chat module. This is mandatory, not a suggested option. - -- **Logos testnet compatibility.** The delivered implementation must be - compatible with Logos testnet 0.3 and 0.4. +No end-to-end multi-party authorisation flow exists on LEZ today: the underlying +primitives are available, but this RFP commissions the first such +implementation. LEZ also provides group-owned shared private accounts, derived +from a single Group Master Secret and documented in the Journey linked under +Resources; proposers should study this feature and state how, and whether, they +use it. ### Risks @@ -333,15 +321,6 @@ Benchmarks must be produced with real proving. Development mode skips proof generation and yields figures that are orders of magnitude optimistic, which is misleading for capacity planning. -#### Signing-layer trust - -The Bybit and WazirX losses were not smart-contract failures; they exploited the -gap between what a signer saw in a UI and what they actually authorised. The -primary mitigation is the Logos module model: the UI is installed and verified -once, not downloaded from a remote server on every use. Usability requirement -U.6 (show the exact decoded action before signing) is a secondary mitigation and -must not be treated as optional polish. - ## 👤 Recommended Team Profile Team experienced with: @@ -356,21 +335,19 @@ Team experienced with: Estimated duration: **6 months** (fresh implementation of the M-of-N program with its private-by-default execution path, the coordination room with in-room -approval collection, and the SDK, CLI, and mini-app). The vault architecture and -privacy posture are settled; vault key custody and the approval-verification -scheme are left to the proposer (see Decisions for Review). +approval collection, and the SDK, CLI, and mini-app). This estimate assumes a team already productive on LEZ. Proposers new to the platform should account for ramp-up separately and say so. -**A phased proposal is welcome.** The in-guest approval verifier is on the -critical path, has no precedent to size against, and its cost determines the -largest workable M. Proposers may structure the work so that an initial phase -establishes the approval-verification benchmark (P.2), the account layout -against the private-account ceiling, and the time-lock design, with the scope -and cost of the remainder fixed once those are known. A proposal that names this -uncertainty and structures around it will be viewed more favourably than one -that prices it silently. +**A phased proposal is welcome.** The approval verifier is on the critical path, +has no precedent to size against, and its cost determines the largest workable +M. Proposers may structure the work so that an initial phase establishes the +approval-verification benchmark (P.2), the account layout against the +private-account ceiling, and the time-lock design, with the scope and cost of +the remainder fixed once those are known. A proposal that names this uncertainty +and structures around it will be viewed more favourably than one that prices it +silently. ## 🌍 Open Source Requirement @@ -401,58 +378,6 @@ All code must be released under the **MIT+Apache2.0 dual License**. - [Journey: Allow different users to interact with same private account](https://github.com/logos-co/logos-docs/issues/321): official Logos journey documenting the shared private account feature -## 🧩 Decisions for Review - -Settled and embedded in the requirements above: - -1. The privacy posture is **private by default**, with the auditability and - transparency options listed in Privacy Architecture. -2. **Approvals flow through the E2EE coordination room**, with the program - verifying the collected approvals at execution (no per-approval on-chain - writes). -3. The vault is **controlled by the multisig program**, with M-of-N enforced by - the program's verified execution rather than by how the vault's keys are - distributed. Member changes are program state changes, not key migrations. - -Group-shared accounts derived from a Group Master Secret are **not** the vault -mechanism: every holder of the group secret gets full spending authority, so a -vault built on one would be advisory rather than enforcing. The feature remains -useful for shared **viewing** of vault activity and for keying the coordination -room, and proposers may use it for those purposes. - -### Open for the proposer to decide - -**Vault key custody.** A spend must ultimately be constructed by some party -holding the vault's spending key. Both models below are viable; the proposer -must choose one, justify it, and document the resulting threat model: - -- **All members hold the vault spending key.** Any member can construct a spend - transaction, but the program rejects it below quorum, so funds are safe once - the vault is initialised. No liveness dependency, no single point of key loss, - and no trusted coordinator. The cost is that "execute" is not a separable role - under F.6, since every member holds what is needed to submit. -- **A designated operator or relayer holds the vault spending key.** Members - hold approval keys only and cannot construct a spend transaction at all, which - makes F.6 role separation fully meaningful. The cost is a trusted coordinator: - a liveness dependency, a single point of key loss, and a censorship vector. - Choosing this model forfeits the no-trusted-coordinator property claimed in - Why This Matters, and the documentation must say so plainly. - -Neither model provides cryptographic k-of-N at the key layer. That requires -threshold cryptography, noted below as a future extension. - -**Approval verification scheme.** How member approvals are verified inside the -program is the proposer's choice, subject to the benchmark required by -Performance requirement P.2 and to meeting Reliability requirement R.1. - -### Future extension (not a deliverable) - -**Threshold cryptography over the vault keys** (for example a FROST-style -scheme) would give cryptographic M-of-N at the key layer, removing the need for -any single party to hold a complete spending key. Tooling is immature and -threshold-signature implementation is out of scope for this RFP; a proposer may -document it as a migration path. - ## ✏️ How to Apply 👉 Submit a proposal using the Issue form: From 8bac5a72cdb3554c6d3ee8c0247825ffe2d341d9 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 15:20:27 +1000 Subject: [PATCH 09/14] RFP-005: revert tier to L Also drop references to platform constraints the RFP no longer describes from the phased-proposal note. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 2 +- RFPs/RFP-005-multisig-and-coordination.md | 13 ++++++------- 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 13602311..3de5cb3c 100644 --- a/README.md +++ b/README.md @@ -80,7 +80,7 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | closed | Developer Tooling & Infrastructure | Closed | | RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | closed | Applications & Integrations | Closed | | RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | closed | Applications & Integrations | Closed | -| RFP-005 | [Multisig and Coordination](RFPs/RFP-005-multisig-and-coordination.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-005 | [Multisig and Coordination](RFPs/RFP-005-multisig-and-coordination.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | closed | Applications & Integrations | Closed | diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 3a8d8ec6..4ee8e9eb 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -1,7 +1,7 @@ --- id: RFP-005 title: Multisig and Coordination -tier: XL +tier: L status: open dependencies: - id: LP-0002 @@ -340,14 +340,13 @@ approval collection, and the SDK, CLI, and mini-app). This estimate assumes a team already productive on LEZ. Proposers new to the platform should account for ramp-up separately and say so. -**A phased proposal is welcome.** The approval verifier is on the critical path, +**A phased proposal is welcome.** Approval verification is on the critical path, has no precedent to size against, and its cost determines the largest workable M. Proposers may structure the work so that an initial phase establishes the -approval-verification benchmark (P.2), the account layout against the -private-account ceiling, and the time-lock design, with the scope and cost of -the remainder fixed once those are known. A proposal that names this uncertainty -and structures around it will be viewed more favourably than one that prices it -silently. +approval-verification benchmark (P.2) and the resulting design constraints, with +the scope and cost of the remainder fixed once those are known. A proposal that +names this uncertainty and structures around it will be viewed more favourably +than one that prices it silently. ## 🌍 Open Source Requirement From c46ea9f93d13ffbd4c5f66d8bda5478d67ca4179 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 15:24:50 +1000 Subject: [PATCH 10/14] RFP-005: add the standard specification disclaimer Every other RFP gained this note on master. RFP-005 is new on this branch so the rebase did not bring it in; copied verbatim from a sibling RFP. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 29 +++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 4ee8e9eb..32dedbcc 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -11,6 +11,35 @@ category: Applications & Integrations # RFP-005 — Multisig and Coordination +> **Note.** This specification describes an outcome that may benefit the Logos +> ecosystem. It is a proposal rather than an instruction. Its requirements +> reflect the technical compatibility with the Logos technology stack and are +> the criteria against which proposals and milestones are evaluated. Logos makes +> no representation as to the legal or regulatory treatment of this +> specification or any implementation of it in any jurisdiction. +> +> Teams implementing it are solely responsible for (i) assessing the risks and +> implications of what they build; (ii) obtaining their own professional advice; +> and (iii) for complying with any legal and regulatory requirements that apply +> to them. Software developed under the Program is published and maintained by +> its developers, not by Logos. +> +> Anyone who chooses to deploy, host, operate or use software developed under +> the Program, whether or not they were awarded a grant under the Program, does +> so at their own risk and is solely responsible for complying with any legal or +> regulatory requirements that apply to them. See the +> [Terms & Conditions](../TERMS_AND_CONDITIONS.md). +> +> Deploying the software described in this RFP, operating any service based on +> it, or carrying on business through it may amount to regulated activity in +> some jurisdictions, including where it involves holding or managing users' +> assets or providing services to others. Whoever conducts any such activity +> does so as principal, in their own name, and is solely responsible for +> assessing its regulatory treatment, including any licensing, registration, +> sanctions or anti-money laundering obligations that may apply to them. Logos +> does not make any representation, provides any advice or assumes any +> responsibility in respect of any such determination or compliance. + ## 🧭 Overview Build a production-ready M-of-N multisig program on the Logos Execution Zone From 90dd85ce2a06e125a05e0646b35c3df299496a04 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 5 Aug 2026 15:28:29 +1000 Subject: [PATCH 11/14] appendix: format with mdformat The appendix was never run through mdformat, so CI failed on every push to this branch. Reformatting only: table column padding and link reflowing to the 80-column wrap. No content changes. Co-Authored-By: Claude Opus 5 (1M context) --- appendix/multisig-coordination-ecosystem.md | 193 ++++++++++---------- 1 file changed, 97 insertions(+), 96 deletions(-) diff --git a/appendix/multisig-coordination-ecosystem.md b/appendix/multisig-coordination-ecosystem.md index 7cdd675c..7d35fdb9 100644 --- a/appendix/multisig-coordination-ecosystem.md +++ b/appendix/multisig-coordination-ecosystem.md @@ -27,11 +27,11 @@ total-value-locked (TVL) is not the applicable metric. Custodied-value figures (each with its basis and caveats): -| Custody layer | Value in custody | Basis and caveats | -| ------------- | ---------------- | ----------------- | -| Safe (EVM) | **US$60B+** | Self-reported by Safe, accessed 2026-08-03: over US$60B secured across 57M+ deployed accounts, US$1T+ cumulative volume processed ([safe.global](https://safe.global)). Lower bound at best; protocol-reported. | -| Squads v4 (Solana) | **US$15B+** | Self-reported by Squads Labs, accessed 2026-08-03: over US$15B secured across 450+ teams ([squads.xyz/protocol](https://squads.xyz/protocol)). Protocol-reported. | -| Bitcoin native multisig (P2WSH proxy) | **~US$86.5B** | 1,365,834 BTC held in P2WSH outputs ([Glassnode supply by output type](https://studio.glassnode.com/charts/supply.SupplyByTxoutType?a=BTC), 2026-04-05 snapshot; subscription data, not independently verifiable from public sources) × US$63,364/BTC ([BitInfoCharts](https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html), 2026-08-03). P2WSH is used almost exclusively for multisig or complex scripts, making it the closest observable proxy for Bitcoin multisig custody. The older P2SH type (~3.96M BTC) is not a usable proxy because it mixes multisig with nested-SegWit single-sig and exchange cold wallets indistinguishably. | +| Custody layer | Value in custody | Basis and caveats | +| ------------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Safe (EVM) | **US$60B+** | Self-reported by Safe, accessed 2026-08-03: over US$60B secured across 57M+ deployed accounts, US$1T+ cumulative volume processed ([safe.global](https://safe.global)). Lower bound at best; protocol-reported. | +| Squads v4 (Solana) | **US$15B+** | Self-reported by Squads Labs, accessed 2026-08-03: over US$15B secured across 450+ teams ([squads.xyz/protocol](https://squads.xyz/protocol)). Protocol-reported. | +| Bitcoin native multisig (P2WSH proxy) | **~US$86.5B** | 1,365,834 BTC held in P2WSH outputs ([Glassnode supply by output type](https://studio.glassnode.com/charts/supply.SupplyByTxoutType?a=BTC), 2026-04-05 snapshot; subscription data, not independently verifiable from public sources) × US$63,364/BTC ([BitInfoCharts](https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html), 2026-08-03). P2WSH is used almost exclusively for multisig or complex scripts, making it the closest observable proxy for Bitcoin multisig custody. The older P2SH type (~3.96M BTC) is not a usable proxy because it mixes multisig with nested-SegWit single-sig and exchange cold wallets indistinguishably. | These figures indicate orders of magnitude, not precise totals. They establish that value in multisig custody is on the order of **US$100B+** across the three @@ -96,12 +96,13 @@ On the account-model chains, these three items are inseparable from how the quorum is enforced. Safe stores its owner set as a linked list and its threshold as a storage slot; Squads stores its members and threshold in a settings account; ZeroDev Kernel stores guardian addresses and weights in contract -storage (see the [Squads settings program -state](https://github.com/Squads-Protocol/smart-account-program/blob/main/programs/squads_smart_account_program/src/state/settings.rs), -the [Safe smart account -contracts](https://github.com/safe-global/safe-smart-account), and the [ZeroDev -Kernel](https://github.com/zerodevapp/kernel)). In all three, the chain must -read this state to enforce the rule, so the state is public by construction. +storage (see the +[Squads settings program state](https://github.com/Squads-Protocol/smart-account-program/blob/main/programs/squads_smart_account_program/src/state/settings.rs), +the +[Safe smart account contracts](https://github.com/safe-global/safe-smart-account), +and the [ZeroDev Kernel](https://github.com/zerodevapp/kernel)). In all three, +the chain must read this state to enforce the rule, so the state is public by +construction. Bitcoin native script (P2SH / P2WSH) reveals the full script (all public keys and the threshold) at spend time. Taproot changes this: a key-path spend using @@ -112,15 +113,15 @@ the executed leaf and hides sibling leaves via the Merkle tree FROST is the outlier: the threshold is enforced cryptographically off-chain, and the chain sees a single Schnorr signature. Signer count, threshold, and the fact -that the account is a multisig at all are invisible ([Komlo & Goldberg, -FROST](https://eprint.iacr.org/2020/852)). +that the account is a multisig at all are invisible +([Komlo & Goldberg, FROST](https://eprint.iacr.org/2020/852)). ### 1.2 Approval attribution and pending proposals (items 4-5) Squads persists each approval as separate on-chain state before execution, which produces a live, queryable pending-proposal view: any observer can see who has -approved and who has not, in real time (see the [Squads -smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). +approved and who has not, in real time (see the +[Squads smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). Safe typically collects signatures off-chain and presents them together in the final `execTransaction` call; owners may optionally record consent early with the on-chain `approveHash` function. @@ -134,14 +135,14 @@ Squads makes approvals public before execution as a live pending view; Safe does not. This is a coordination-visibility difference, not an audit-trail advantage of one over the other. -A separate and distinct property, noted in the [Check Point Bybit -analysis](https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/), -is *intent verifiability at signing -time*: with off-chain signature collection there is no on-chain record that a -signer intended the transaction they actually signed, which is the gap both the -Bybit (February 2025, ~US$1.5B) and WazirX (July 2024, ~US$235M) incidents -exploited at the UI layer. This is about what a signer can verify at the moment -of signing, not about what survives on-chain afterwards. +A separate and distinct property, noted in the +[Check Point Bybit analysis](https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/), +is *intent verifiability at signing time*: with off-chain signature collection +there is no on-chain record that a signer intended the transaction they actually +signed, which is the gap both the Bybit (February 2025, ~US$1.5B) and WazirX +(July 2024, ~US$235M) incidents exploited at the UI layer. This is about what a +signer can verify at the moment of signing, not about what survives on-chain +afterwards. ### 1.3 Action, holdings, execution linkage (items 6-8) @@ -162,12 +163,13 @@ Coordination content is off-chain in every ecosystem, because signing protocols define message formats but not transports (see section 4). What differs is what the transport leaks. Bitcoin coordinators (Sparrow, Specter) exchange partially signed transactions over a channel the user chooses (SD card, QR, USB, file -share) and add no transport of their own. Safe's self-hosted transaction -service is a purpose-built relay; whoever operates it sees pending transaction -hashes, collected signatures, and which owners have approved (see the +share) and add no transport of their own. Safe's self-hosted transaction service +is a purpose-built relay; whoever operates it sees pending transaction hashes, +collected signatures, and which owners have approved (see the [safe-transaction-service](https://github.com/safe-global/safe-transaction-service) -repository and the [Safe service -architecture](https://docs.safe.global/core-api/service-architecture) docs). +repository and the +[Safe service architecture](https://docs.safe.global/core-api/service-architecture) +docs). The co-signing social graph (that a particular set of accounts jointly administers one multisig) is not treated as a distinct privacy concern by any @@ -232,9 +234,9 @@ Distributing the viewing key creates a **view-only auditor**: the recipient learns the exact account state (balance, nonce, program data) and cannot move funds. The cryptography supports this today, but it is not exposed as a wallet command. Two caveats matter in practice: a shared viewing key **cannot be -revoked** (rotating the audience requires creating a fresh account and -migrating funds), and what the auditor sees is the exact state — there is no -coarser disclosure built in. +revoked** (rotating the audience requires creating a fresh account and migrating +funds), and what the auditor sees is the exact state — there is no coarser +disclosure built in. **Group-owned shared accounts.** A private account can be shared through a single Group Master Secret (GMS): every GMS holder derives *identical* spending @@ -263,16 +265,16 @@ spending exists and is integration-tested How inspectable a treasury must be differs by organisation: a corporate or operational multisig typically needs a limited auditor group, while a DAO -treasury typically needs its whole membership — including members who join -later — to be able to verify that the treasury is secured the way the key -holders claim. The key-separation properties in section 2.1 make three -configurations available on LEZ: +treasury typically needs its whole membership — including members who join later +— to be able to verify that the treasury is secured the way the key holders +claim. The key-separation properties in section 2.1 make three configurations +available on LEZ: -| Configuration | On-chain visibility | Who can audit | Notes | -| ---------------------------------------- | ------------------------------ | ------------------------------------------ | ---------------------------------------------------------------------------------------------------- | -| Public treasury account | Full (state visible to anyone) | Any observer | Simplest; sacrifices all holdings privacy | -| Private account + shared viewing key | Commitment only | Everyone holding the viewing key | Continuous inspection of exact state; doubles as standing proof of holding for new members; not revocable | -| Private account + zero-knowledge balance proof | Commitment only | Whoever the proof is published to | Would prove "balance ≥ X" against the on-chain commitment without revealing the exact balance; the LEE runs arbitrary RISC-V circuits, but no such circuit exists as of 2026-08-03 | +| Configuration | On-chain visibility | Who can audit | Notes | +| ---------------------------------------------- | ------------------------------ | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Public treasury account | Full (state visible to anyone) | Any observer | Simplest; sacrifices all holdings privacy | +| Private account + shared viewing key | Commitment only | Everyone holding the viewing key | Continuous inspection of exact state; doubles as standing proof of holding for new members; not revocable | +| Private account + zero-knowledge balance proof | Commitment only | Whoever the proof is published to | Would prove "balance ≥ X" against the on-chain commitment without revealing the exact balance; the LEE runs arbitrary RISC-V circuits, but no such circuit exists as of 2026-08-03 | ## 3. Quorum privacy across ecosystems @@ -295,12 +297,12 @@ Two observations hold across the whole survey: 2. MuSig2 achieves this only for n-of-n (all signers must participate). Genuine k-of-n structural privacy on Bitcoin requires FROST, which as of 2026-07-06 - is still at BIP-draft stage ([ChillDKG BIP - draft](https://github.com/BlockstreamResearch/bip-frost-dkg)) and supported - only by purpose-built hardware (Frostsnap's ESP32-C3 device; see the - [Frostsnap FROST protocol - docs](https://frostsnap.com/docs/frost-protocol/)); no mainstream hardware - wallet supports it. + is still at BIP-draft stage + ([ChillDKG BIP draft](https://github.com/BlockstreamResearch/bip-frost-dkg)) + and supported only by purpose-built hardware (Frostsnap's ESP32-C3 device; + see the + [Frostsnap FROST protocol docs](https://frostsnap.com/docs/frost-protocol/)); + no mainstream hardware wallet supports it. The centralised industry "solution" to account-model privacy (a trusted relayer or co-processor that manages signer identity off-chain and presents a single @@ -344,8 +346,9 @@ Three facts about coordination bear on a product decision: - **Threshold-signature schemes carry their own session protocol.** FROST's DKG and signing rounds are a structured message exchange that runs within the protocol; a coordinator app (or a peer-to-peer layer) implements it without - any external messaging service (see the [Frostsnap design - decisions](https://frostsnap.com/docs/design-decisions/) docs and the + any external messaging service (see the + [Frostsnap design decisions](https://frostsnap.com/docs/design-decisions/) + docs and the [ChillDKG BIP draft](https://github.com/BlockstreamResearch/bip-frost-dkg)). Frostsnap deliberately runs this over USB serial rather than airgapped QR, because a k-of-n session over QR codes needs many scans per transaction and @@ -367,17 +370,16 @@ controls that shape what an operational multisig can express. (Initiate / Vote / Execute), so a proposing key need not be a voting key, and execution can be a separate role. Program invariants require at least one signer with each permission and forbid an impossible threshold (see the - [Squads settings program - state](https://github.com/Squads-Protocol/smart-account-program/blob/main/programs/squads_smart_account_program/src/state/settings.rs)). - ZeroDev Kernel expresses roles as weighted guardians, where the threshold is - a minimum cumulative weight + [Squads settings program state](https://github.com/Squads-Protocol/smart-account-program/blob/main/programs/squads_smart_account_program/src/state/settings.rs)). + ZeroDev Kernel expresses roles as weighted guardians, where the threshold is a + minimum cumulative weight ([WeightedECDSAValidator.sol](https://github.com/zerodevapp/kernel/blob/master/src/validator/WeightedECDSAValidator.sol)). - **Time locks and cancellation.** Squads supports a per-multisig time lock (0 to about three months) enforced on-chain between approval and execution, and allows an approved proposal to be cancelled by a threshold of cancellation - votes before it executes (see the [Squads - smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). + votes before it executes (see the + [Squads smart-account-program](https://github.com/Squads-Protocol/smart-account-program)). Safe's core contract has no time lock; it must be added as a guard or module ([safe-smart-account](https://github.com/safe-global/safe-smart-account)). @@ -396,12 +398,11 @@ controls that shape what an operational multisig can express. This is powerful and dangerous: a module has unlimited authority, and the SquidRouter incident (May 2026, ~US$3.2M) drained 86 Safes through a vulnerable third-party module that owners had enabled - ([Cryptopolitan - report](https://www.cryptopolitan.com/3-2m-drained-gnosis-safes-hack-base-ethereum/)). + ([Cryptopolitan report](https://www.cryptopolitan.com/3-2m-drained-gnosis-safes-hack-base-ethereum/)). ERC-4337 uses a modular validator-plugin model with a defined install/uninstall lifecycle - ([ERC-7579](https://eips.ethereum.org/EIPS/eip-7579); [ZeroDev - Kernel](https://github.com/zerodevapp/kernel)). + ([ERC-7579](https://eips.ethereum.org/EIPS/eip-7579); + [ZeroDev Kernel](https://github.com/zerodevapp/kernel)). ## 6. Composition: how a multisig triggers actions @@ -448,9 +449,9 @@ Two operational facts recur across the survey and bear on any real deployment: Bitcoin Core or Electrum backend. Safe can run as a full Docker stack (many services) or CLI-only with no infrastructure. Squads needs only an RPC node. ERC-4337 requires a bundler - ([ERC-4337](https://eips.ethereum.org/EIPS/eip-4337); [eth-infinitism - bundler](https://github.com/eth-infinitism/bundler), [Pimlico - alto](https://github.com/pimlicolabs/alto)), which must be separately + ([ERC-4337](https://eips.ethereum.org/EIPS/eip-4337); + [eth-infinitism bundler](https://github.com/eth-infinitism/bundler), + [Pimlico alto](https://github.com/pimlicolabs/alto)), which must be separately self-hosted or is defaulted to a hosted provider. ## 8. Summary of observations @@ -476,10 +477,10 @@ Two operational facts recur across the survey and bear on any real deployment: - LEE key separation makes a private account selectively inspectable: sharing the viewing key yields a view-only auditor (irrevocable short of account - migration). LEZ group-shared accounts are effectively N-of-N with no - on-chain membership record and no revocation, so M-of-N must be layered on - top (section 2.1); three auditability configurations are available to a - treasury depending on its audience (section 2.2). + migration). LEZ group-shared accounts are effectively N-of-N with no on-chain + membership record and no revocation, so M-of-N must be layered on top (section + 2.1); three auditability configurations are available to a treasury depending + on its audience (section 2.2). - "On-chain versus off-chain approval" is a coordination-visibility choice, not an audit-trail trade-off: both models yield an on-chain authorisation record @@ -490,34 +491,34 @@ Two operational facts recur across the survey and bear on any real deployment: ## References -| Source | URL | Access date | -| ---------------------------------------- | ------------------------------------------------------------------------------------ | ----------- | -| Introduction to the Logos Execution Zone | https://docs.logos.co/lez | 2026-07-07 | -| Logos Execution Zone codebase (key protocol, encryption, wallet group CLI, shared-account integration tests, benchmarks) | https://github.com/logos-blockchain/logos-execution-zone | 2026-08-03 | -| Safe (protocol-reported custody figures) | https://safe.global | 2026-08-03 | -| Squads protocol (protocol-reported custody figures) | https://squads.xyz/protocol | 2026-08-03 | -| Glassnode supply by output type (subscription data) | https://studio.glassnode.com/charts/supply.SupplyByTxoutType?a=BTC | snapshot 2026-04-05 | -| BitInfoCharts (BTC price reference) | https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html | 2026-08-03 | -| Squads smart-account-program | https://github.com/Squads-Protocol/smart-account-program | 2026-07-06 | -| Safe smart account | https://github.com/safe-global/safe-smart-account | 2026-07-06 | -| Safe transaction service | https://github.com/safe-global/safe-transaction-service | 2026-07-06 | -| Safe service architecture (docs) | https://docs.safe.global/core-api/service-architecture | 2026-07-06 | -| Frostsnap | https://github.com/frostsnap/frostsnap | 2026-07-06 | -| Frostsnap FROST protocol docs | https://frostsnap.com/docs/frost-protocol/ | 2026-07-06 | -| Frostsnap design decisions | https://frostsnap.com/docs/design-decisions/ | 2026-07-06 | -| FROST paper (Komlo & Goldberg) | https://eprint.iacr.org/2020/852 | 2026-07-06 | -| ChillDKG BIP draft | https://github.com/BlockstreamResearch/bip-frost-dkg | 2026-07-06 | -| ZeroDev Kernel | https://github.com/zerodevapp/kernel | 2026-07-06 | -| Sparrow Wallet | https://github.com/sparrowwallet/sparrow | 2026-07-06 | -| Specter Desktop | https://github.com/cryptoadvance/specter-desktop | 2026-07-06 | -| rust-bitcoin | https://github.com/rust-bitcoin/rust-bitcoin | 2026-07-06 | -| BIP-174 (PSBT) | https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki | 2026-07-06 | -| BIP-327 (MuSig2) | https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki | 2026-07-06 | -| BIP-341 (Taproot) | https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki | 2026-07-06 | -| BIP-370 (PSBT v2) | https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki | 2026-07-06 | -| ERC-4337 (account abstraction) | https://eips.ethereum.org/EIPS/eip-4337 | 2026-07-06 | -| ERC-7579 (modular smart accounts) | https://eips.ethereum.org/EIPS/eip-7579 | 2026-07-06 | -| Bybit incident analysis (Check Point) | https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/ | 2026-07-06 | -| WazirX hack analysis (QuillAudits) | https://www.quillaudits.com/blog/hack-analysis/wazirx-235m-hack | 2026-07-06 | -| SquidRouter module incident (Cryptopolitan) | https://www.cryptopolitan.com/3-2m-drained-gnosis-safes-hack-base-ethereum/ | 2026-07-06 | -| logos-co/lez-multisig | https://github.com/logos-co/lez-multisig | 2026-07-07 | +| Source | URL | Access date | +| ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | ------------------- | +| Introduction to the Logos Execution Zone | https://docs.logos.co/lez | 2026-07-07 | +| Logos Execution Zone codebase (key protocol, encryption, wallet group CLI, shared-account integration tests, benchmarks) | https://github.com/logos-blockchain/logos-execution-zone | 2026-08-03 | +| Safe (protocol-reported custody figures) | https://safe.global | 2026-08-03 | +| Squads protocol (protocol-reported custody figures) | https://squads.xyz/protocol | 2026-08-03 | +| Glassnode supply by output type (subscription data) | https://studio.glassnode.com/charts/supply.SupplyByTxoutType?a=BTC | snapshot 2026-04-05 | +| BitInfoCharts (BTC price reference) | https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html | 2026-08-03 | +| Squads smart-account-program | https://github.com/Squads-Protocol/smart-account-program | 2026-07-06 | +| Safe smart account | https://github.com/safe-global/safe-smart-account | 2026-07-06 | +| Safe transaction service | https://github.com/safe-global/safe-transaction-service | 2026-07-06 | +| Safe service architecture (docs) | https://docs.safe.global/core-api/service-architecture | 2026-07-06 | +| Frostsnap | https://github.com/frostsnap/frostsnap | 2026-07-06 | +| Frostsnap FROST protocol docs | https://frostsnap.com/docs/frost-protocol/ | 2026-07-06 | +| Frostsnap design decisions | https://frostsnap.com/docs/design-decisions/ | 2026-07-06 | +| FROST paper (Komlo & Goldberg) | https://eprint.iacr.org/2020/852 | 2026-07-06 | +| ChillDKG BIP draft | https://github.com/BlockstreamResearch/bip-frost-dkg | 2026-07-06 | +| ZeroDev Kernel | https://github.com/zerodevapp/kernel | 2026-07-06 | +| Sparrow Wallet | https://github.com/sparrowwallet/sparrow | 2026-07-06 | +| Specter Desktop | https://github.com/cryptoadvance/specter-desktop | 2026-07-06 | +| rust-bitcoin | https://github.com/rust-bitcoin/rust-bitcoin | 2026-07-06 | +| BIP-174 (PSBT) | https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki | 2026-07-06 | +| BIP-327 (MuSig2) | https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki | 2026-07-06 | +| BIP-341 (Taproot) | https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki | 2026-07-06 | +| BIP-370 (PSBT v2) | https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki | 2026-07-06 | +| ERC-4337 (account abstraction) | https://eips.ethereum.org/EIPS/eip-4337 | 2026-07-06 | +| ERC-7579 (modular smart accounts) | https://eips.ethereum.org/EIPS/eip-7579 | 2026-07-06 | +| Bybit incident analysis (Check Point) | https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/ | 2026-07-06 | +| WazirX hack analysis (QuillAudits) | https://www.quillaudits.com/blog/hack-analysis/wazirx-235m-hack | 2026-07-06 | +| SquidRouter module incident (Cryptopolitan) | https://www.cryptopolitan.com/3-2m-drained-gnosis-safes-hack-base-ethereum/ | 2026-07-06 | +| logos-co/lez-multisig | https://github.com/logos-co/lez-multisig | 2026-07-07 | From a1f2165767f49892dc0c2dd38b61534de843fbf3 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 8 Sep 2026 19:24:05 +1000 Subject: [PATCH 12/14] RFP-005: apply legal review feedback from spec review doc Applies the comments left on the "RFP Program - Drafting measures and spec reviews" doc: - Replace "production-ready" with an explicit audit deliverable and state that deployment/operation beyond devnet/testnet is out of scope, so the RFP does not imply a production deployment obligation. - Add Supportability #13, an audit programme requirement, matching the pattern already used in RFP-008 and RFP-012. - Neutralise procurement-flavoured wording: "this RFP is the vehicle for delivering that" and the three uses of "commissions" become invitations for proposals. - Drop "will be viewed more favourably", which reads as a selection commitment, in favour of a direct instruction to proposers. - Clarify that the module UI's developer signature is verified at install time, rather than the vaguer "installed and verified once". - Clarify that teams publish modules through their own catalog built from the template repo, not into a Logos-maintained catalog. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 42 +++++++++++++++-------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 32dedbcc..967082f7 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -42,14 +42,18 @@ category: Applications & Integrations ## 🧭 Overview -Build a production-ready M-of-N multisig program on the Logos Execution Zone -(LEZ), together with an in-band coordination channel so signers can propose, +Build an audited M-of-N multisig program on the Logos Execution Zone (LEZ), +together with an in-band coordination channel so signers can propose, deliberate, collect approvals, and reach quorum without leaving the application. A multisig is the execution layer for shared custody, treasuries, and DAOs. The program is designed and implemented from scratch for LEZ, taking as its baseline the properties LEZ makes uniquely possible: multisig state that is private by default, and a coordination channel that is encrypted and metadata-resistant. +The deliverable is a codebase carried through an independent security audit +(Supportability requirement #13) and deployed on devnet/testnet. Deploying or +operating the software beyond that is outside the scope of this RFP. + Multisig is the single most widely used custody primitive in the ecosystem, and the value in multisig custody today is immense. Safe (formerly Gnosis Safe), the dominant standard on Ethereum, is deployed across 86 networks and self-reports @@ -78,7 +82,8 @@ session, at the cost of hardware immaturity and, for MuSig2, an n-of-n-only limitation. Every implementation that keeps the quorum on-chain is transparent. On LEZ, the same multisig program can run over private accounts, so the chain records only a commitment to the post-state and a validity proof, without giving -up k-of-n. This RFP is the vehicle for delivering that. +up k-of-n. This RFP invites proposals for an implementation that explores this +design space. ## ✅ Scope of Work @@ -154,8 +159,9 @@ up k-of-n. This RFP is the vehicle for delivering that. This addresses the signing-layer attack surface behind the Bybit and WazirX losses, in which signers authorised what a compromised UI showed them rather than what was actually executed. It complements the primary mitigation, which - is the Logos module model itself: the UI is installed and verified once - rather than fetched from a remote server on every use. + is the Logos module model itself: the UI ships as a module package whose + developer signature is verified at install time, rather than being fetched + from a remote server on every use. 7. Failed or rejected proposals and executions must return clear, actionable error messages. @@ -216,8 +222,16 @@ up k-of-n. This RFP is the vehicle for delivering that. for the CLI, covering the core operator journey. 11. Provide Figma designs or equivalent for the mini-app GUI, including the proposal list and the coordination room. -12. Publish resulting modules in the - [Logos modules catalog](https://github.com/logos-co/logos-modules-release-base). +12. Publish the resulting modules in a module catalog of the team's own, built + from the + [Logos module catalog template](https://github.com/logos-co/logos-modules-release-base), + so the modules are installable by Logos clients. Publication into any + Logos-maintained catalog is not part of this RFP. +13. **Audit programme.** The proposal must include a planned audit programme + covering the multisig program and its approval-verification path. The + proposal must name at least one tier-1 audit firm the applicant intends to + engage, include the audit budget as a line item, and include the audit + timeline. Audit reports must be published with the codebase. ### Soft Requirements @@ -320,7 +334,7 @@ Supportability requirements. Proposers should confirm the current state of each against the Resources section before relying on it. No end-to-end multi-party authorisation flow exists on LEZ today: the underlying -primitives are available, but this RFP commissions the first such +primitives are available, but this RFP invites proposals for the first such implementation. LEZ also provides group-owned shared private accounts, derived from a single Group Master Secret and documented in the Journey linked under Resources; proposers should study this feature and state how, and whether, they @@ -373,9 +387,9 @@ platform should account for ramp-up separately and say so. has no precedent to size against, and its cost determines the largest workable M. Proposers may structure the work so that an initial phase establishes the approval-verification benchmark (P.2) and the resulting design constraints, with -the scope and cost of the remainder fixed once those are known. A proposal that -names this uncertainty and structures around it will be viewed more favourably -than one that prices it silently. +the scope and cost of the remainder fixed once those are known. Proposals should +identify this uncertainty expressly and explain how it is reflected in the +proposed phasing, scope and pricing. ## 🌍 Open Source Requirement @@ -385,13 +399,13 @@ All code must be released under the **MIT+Apache2.0 dual License**. - [Logos Documentation](https://github.com/logos-co/logos-docs) - [logos-co/lez-multisig](https://github.com/logos-co/lez-multisig): a public - multisig proof-of-concept sample app on LEZ; prior art only — this RFP - commissions a fresh design and implementation. Note that its architecture is + multisig proof-of-concept sample app on LEZ; prior art only — this RFP invites + proposals for a fresh design and implementation. Note that its architecture is incompatible with private accounts: it requires member accounts to be fresh zero-nonce keypairs claimed by the multisig program, which private accounts cannot satisfy because they are owned by the privacy protocol and increment the nonce on every use. Treat it as a reference for the public path only. -- **LP-0002, Private M-of-N Multisig** (open λ prize): commissions a private +- **LP-0002, Private M-of-N Multisig** (open λ prize): calls for a private M-of-N primitive for LEZ using anonymous threshold proofs, where the verifier confirms a threshold was met without recording which members approved. It overlaps this RFP's ground but is unclaimed, and its anonymity model differs From edc8b5eda963eb37b6b44d63aad48dcfdb02c67b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 8 Sep 2026 20:32:29 +1000 Subject: [PATCH 13/14] RFP-005: align audit programme with RFP-008 and RFP-012 wording Match the established pattern used by the other RFPs that carry an audit programme requirement: name the example tier-1 firms, enumerate the components in scope, and tie the audit timeline and report publication to any mainnet recommendation. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index 967082f7..e820a598 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -228,10 +228,14 @@ design space. so the modules are installable by Logos clients. Publication into any Logos-maintained catalog is not part of this RFP. 13. **Audit programme.** The proposal must include a planned audit programme - covering the multisig program and its approval-verification path. The + covering the multisig program, its approval-verification path, the + configuration-change and time-lock logic, and the spending-limit policy. The proposal must name at least one tier-1 audit firm the applicant intends to - engage, include the audit budget as a line item, and include the audit - timeline. Audit reports must be published with the codebase. + engage (for example: OpenZeppelin, Trail of Bits, Spearbit, Cantina, + ChainSecurity, Certora, Halborn), include the audit budget as a line item in + the proposal, and include the audit timeline ahead of any mainnet + recommendation. Audit reports must be published with the codebase before + mainnet deployment is recommended. ### Soft Requirements From aab3ef7ac557602b603758b444e8d9a0b650056b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 9 Sep 2026 11:48:03 +1000 Subject: [PATCH 14/14] RFP-005: apply tracked-change suggestions from spec review doc The review doc carried Google Docs suggestions in addition to comments. These are tracked changes rather than comment threads, so they were missed in the first pass. All three, from Noelle Laguea: - Fix the disclaimer's verb agreement after "does not": "provides any advice or assumes any responsibility" becomes "provide any advice or assume any responsibility". The same wording appears in the other RFPs and the template, left for a separate pass. - Reword the admin-authority sentence in Why This Matters to name who shares control. - Replace "A proposal that omits it entirely is not penalised" with "Proposals may omit this soft requirement", removing wording that reads as a selection commitment. Co-Authored-By: Claude Opus 5 (1M context) --- RFPs/RFP-005-multisig-and-coordination.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/RFPs/RFP-005-multisig-and-coordination.md b/RFPs/RFP-005-multisig-and-coordination.md index e820a598..b43c5c8e 100644 --- a/RFPs/RFP-005-multisig-and-coordination.md +++ b/RFPs/RFP-005-multisig-and-coordination.md @@ -37,7 +37,7 @@ category: Applications & Integrations > does so as principal, in their own name, and is solely responsible for > assessing its regulatory treatment, including any licensing, registration, > sanctions or anti-money laundering obligations that may apply to them. Logos -> does not make any representation, provides any advice or assumes any +> does not make any representation, provide any advice or assume any > responsibility in respect of any such determination or compliance. ## 🧭 Overview @@ -72,8 +72,8 @@ applied cryptography. ## 🔥 Why This Matters Shared custody is a precondition for organisations to operate on Logos. Without -a production multisig, there is no treasury, no DAO execution layer, and no -shared control of protocol admin authorities. +a production multisig, there is no treasury, no DAO execution layer, and no way +for those who deploy programs to share control of protocol admin authorities. LEZ also makes it possible to close a gap no sovereign multisig has closed. Every existing implementation that keeps multisig structure private (FROST, @@ -253,8 +253,7 @@ If possible. requires a second, purpose-built zero-knowledge circuit that does not exist and whose verifying key would need to be established and trusted. A proposer may scope this as a research deliverable with its own budget, or document a - design for later implementation. A proposal that omits it entirely is not - penalised. + design for later implementation. Proposals may omit this soft requirement. ### Coordination Architecture