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.

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, provide any advice or assume any responsibility in respect of any such determination or compliance.

🧭 Overview

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 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 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 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, 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 giving up k-of-n. This RFP invites proposals for an implementation that explores this design space.

✅ 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 can be executed, and the program verifies the approvals at execution. Proposals carry an expiry after which the program rejects execution. Proposals and approvals may be recorded on-chain or collected off-chain (for example, through the coordination room in F.9); proposers must state which. Either way, under the private posture, neither a pending proposal nor its approvals publishes the action payload on-chain in the clear or outside the coordination room.
3. Execute approved actions on any arbitrary program deployed in the given LEZ.
4. 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. 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.
5. 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.
6. 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 what guarantee the implementation delivers for each role.
7. 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.
8. 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.
9. Provision an end-to-end-encrypted coordination room per multisig using the Logos chat module, scoped to the multisig's members. The room carries human deliberation and, where approvals are collected off-chain (F.2), proposals and member approvals. Given a multisig, its room can be provisioned by a defined mechanism that binds each member's LEZ account to a chat identity; proposers must specify this mechanism. 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 a Logos multisig module whose API other Logos modules can call to interact with the multisig (create, propose, approve, reject, execute, manage members and policies).
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 but must support all essential operations.
4. Provide an IDL for the LEZ program, using the SPEL framework.
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 under each disclosure mechanism.
6. Before a member signs an approval, the mini-app must decode and display the action from the exact bytes the approval signs (target program, decoded instruction, amounts), using the registry in F.4, rather than from a description supplied by the proposer or a remote service. This addresses the signing-layer attack surface behind the Bybit and WazirX losses, in which what signers were shown differed from what they signed. It complements the primary mitigation, which 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.

Reliability

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

Performance

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

1. The multisig program runs on the Logos Execution Zone (LEZ) and uses LEZ private accounts for its private-by-default posture.
2. The per-multisig coordination room is built on the Logos chat module.
3. The delivered implementation is compatible with Logos testnet 0.3 and 0.4.
4. The multisig program is deployed and tested on LEZ devnet/testnet.
5. End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI.
6. CI must be green on the default branch.
7. 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.
8. 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.
9. Provide API documentation in repo for the multisig module, covering every call it exposes and the developer integration journey.
10. Provide documentation in repo 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 the resulting modules in a module catalog of the team's own, built from the Logos module catalog template, 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, 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 (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 any production deployment of the software.

+ Privacy

1. Under the private posture, no LEZ transaction the multisig submits publishes data identifying a member's account as belonging to the multisig, or identifying the member's role in it (proposer, approver, executor).
2. Under the private posture, no message the coordination room sends over its transport publishes data identifying a chat identity as belonging to the multisig, or identifying its role in it.
3. Proposals must document every correlation the design leaves observable across the two layers, including timing and patterns between room traffic and LEZ transactions, and the LEZ-to-chat identity binding: which signal carries it, why it remains, and what an observer of both layers can infer from it.

Soft Requirements

If possible.

Functionality

1. Support weighted approvals, where members carry numeric weights and the threshold is a minimum cumulative weight.
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. Proposals may omit this soft requirement.
3. Mixed postures. Allow the operator to choose, at creation, which of the data items listed in the Privacy Architecture section are public and which are private, beyond the fully private and fully public postures (for example, public holdings with a private member set). Proposals must state which combinations they support and what each combination reveals.

Coordination Architecture

Every multisig provisions one end-to-end-encrypted room using the Logos chat module, scoped to its members. The room carries:

• Human deliberation: the discussion among signers about whether to approve.
• Machine coordination, where approvals are collected off-chain (F.2): 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.

Where approvals are collected in the room, the program's verification at execution (R.1) is the only authority on their validity; the room carries no trust for validity. Proposals must document what a room participant can do by withholding, reordering, replaying, or injecting proposals and approvals, or by presenting different members with different views of the room, and how the design detects or tolerates each.

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. Collecting approvals through the room also removes per-approval on-chain writes and keeps pending-proposal metadata off-chain even for a public-posture multisig; either approach yields a verifiable record of who authorised an action at execution.

LEZ accounts and Logos chat identities are independent: no binding between a member's LEZ account and a chat identity is defined today. Proposals must specify the mechanism that establishes this binding, how a room is provisioned from a multisig's member set (including any invite and accept step), and, where approvals are collected in the room, how the program verifies that each was signed by the LEZ account of a member.

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

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. The Privacy hard requirements state what each layer may publish. Mixed postures, where some items are public and others private, are soft requirement #3 in Functionality.

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 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 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 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 Logos components named in the 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 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 use it.

Risks

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. On-chain approvals add a transaction per approval, which off-chain collection avoids; either way, 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.

👤 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: 6 months (fresh implementation of the M-of-N program with its private-by-default execution path, the coordination room, approval collection, and the multisig module, 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. 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) and the resulting design constraints, with 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

All code must be released under the MIT+Apache2.0 dual License.

Resources

• Logos Documentation
• logos-co/lez-multisig: a public 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): 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 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: the public/private account model this RFP relies on
• Logos Chat Module: documentation for building modules that use the chat module API
• Journey: Allow different users to interact with same private account: official Logos journey documenting the shared private account feature

✏️ How to Apply

👉 Submit a proposal using the Issue form:

Submit Proposal

We typically respond within 14 days. For clarification questions, please use Discussions.