New RFP : RFP-005 - Multisig and Coordination

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 teams deploying programs to share control of protocol admin authorities.

There’s also a gap here that no sovereign multisig has closed. Safe and Squads, the dominant standard on Ethereum and its Solana analogue, are fully transparent by construction: members, threshold, every approval and every action live as public on-chain state, because the chain must read the quorum in order to enforce it. The implementations that do keep structure private, FROST and MuSig2, get there by moving the quorum off-chain into a cryptographic session and pay for it in hardware immaturity and, for MuSig2, an n-of-n-only limitation.

On LEZ the same multisig program can run over private accounts. The chain records only a commitment to the post-state and a validity proof, without giving up k-of-n. RFP-005 invites proposals to build that.

What you’d build

  • An M-of-N multisig program on LEZ, private by default over LEZ private accounts, executing approved actions on any arbitrary program deployed in the zone
  • An end-to-end-encrypted coordination room per multisig on the Logos chat module, carrying both signer deliberation and the collection of approvals, so quorum is reached without leaving the application
  • Configuration changes, add or remove a member and change the threshold, through the same M-of-N flow, so structural changes can’t bypass the quorum
  • Role separation across propose, approve and execute, an optional per-multisig time lock and an optional spending-limit policy
  • A registry for proposal code and target programs, so that before signing, a member sees the action decoded from the exact bytes the approval signs, rather than a description supplied by the proposer or a remote service
  • An operator-selectable fully public posture, plus selective disclosure of a private multisig’s state to a chosen audience, narrow as a named auditor or wide as all members of a DAO, without granting that audience spending power
  • A Logos multisig module whose API other Logos modules can call, a CLI on the Logos core headless framework, a QML mini-app loadable in Basecamp and an IDL via SPEL

Is this a fit for your studio?

The profile the spec asks for:

  • 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

Engagement details

  • Tier: L
  • Estimated duration: 6 months, assuming a team already productive on LEZ. New to the platform? Account for ramp-up separately and say so.
  • Phasing: welcome, and actively encouraged. Approval-verification cost scales with M, has no precedent on LEZ to size against and determines the largest workable M. You may structure an initial phase that establishes the approval-verification benchmark (P.2) and the design constraints that follow from it, with the scope and cost of the remainder fixed once they’re known. Identify the uncertainty expressly and explain how your phasing, scope and pricing reflect it.
  • 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 will not be accepted.
  • Audit: your proposal must include a planned audit programme, name at least one tier-1 audit firm you intend to engage, carry the audit budget as a line item and set the audit timeline ahead of any mainnet recommendation. Reports are published with the codebase before any production deployment.
  • Licence: MIT + Apache 2.0 dual
  • Submissions close: 16 October 2026

How to apply

Read the spec: rfp/RFPs/RFP-005-multisig-and-coordination.md at master · logos-co/rfp · GitHub

Submit through the proposal form, selecting RFP-005 — Multisig and Coordination from the RFP ID dropdown: Sign in to GitHub · GitHub

We typically respond within 14 days.

Questions on scope, or on the Logos components involved, private accounts, the chat module, SPEL, are very welcome in this thread. Ask early and keep coming back as you write. We’d much rather resolve a scoping question now than read around it in a proposal later.

By applying you agree to the Logos RFP Terms and Conditions highlighted in the logos-co/rfp repository.

2 Likes

To the Logos RFP team, concerning RFP-005:

We are assessing a phased proposal with an initial real-proof approval-verification study before the larger implementation is priced. Before committing substantial work, please confirm:

  1. What budget is currently approved and reserved for RFP-005, what remains available, and whether a separately paid feasibility phase is eligible?
  2. Which legal entity would be the grantor, who approves the allocation, who signs with authority, and who accepts milestones?
  3. Can the agreement require fixed USDT units on Ethereum, a payment deadline following objective milestone acceptance, and no discretionary fiat/token substitution? Can the receiving address be provided when an accepted milestone becomes payable?
  4. Can we review the grant-agreement template and incorporated terms before applying or undertaking implementation? What funding security and cancellation/payment provisions are available?
  5. Which recipient identity, jurisdiction, tax and eligibility documents are mandatory, and what technical-team evidence is required for a phased application?
  6. Does the October 16 submission deadline have a specific time/timezone, and may a conditional phased proposal be considered while these contracting questions are resolved?

This is a clarification request, not an application, acceptance of terms or authority to incur expenses.