RFP-005: Multisig and Coordination by fryorcraken · Pull Request #113 · logos-co/rfp

fryorcraken · 2026-07-08T03:03:02Z

Fixes logos-co/ecosystem#121

Adds RFP-005 — Multisig and Coordination and its ecosystem-behaviour appendix.

What's here

RFPs/RFP-005-multisig-and-coordination.md — the RFP (tier L). Commissions a
fresh M-of-N multisig program for LEZ, private by default, with an
end-to-end-encrypted per-multisig coordination room built on the Logos chat
module. Deliverables also include an SDK, a QML mini-app, a CLI on the Logos
core headless framework, a SPEL IDL, and a registry for proposal code and
target programs.
appendix/multisig-coordination-ecosystem.md — facts-and-observations
appendix surveying Bitcoin, Ethereum, and Solana multisig behaviour. Leads
with a data inventory: the ten distinct data and metadata items a multisig
involves, whether each could be private on LEZ, and what Safe, Squads,
ERC-4337, Bitcoin script, FROST, and MuSig2 do with each. Supporting context
for reviewers; the RFP is self-contained and does not reference it.
README.md — RFP-005 registered in the index.

Design posture

Private by default. The multisig runs over LEZ private accounts, with
operator-selectable public posture, selective disclosure to a defined
audience, and ongoing assurance for parties joining later. Auditability needs
are framed per use case: a corporate treasury typically needs a narrow
audience, a DAO a wider one.
Approvals flow through the coordination room, with the program verifying
the collected approvals at execution rather than writing each approval
on-chain.
Platform mandates are Supportability requirements (S.1–S.3): runs on LEZ
using private accounts, coordination room on the Logos chat module, and
compatibility with Logos testnet 0.3 and 0.4.

Notes

The RFP states what is required rather than how to achieve it. It
deliberately avoids describing LEZ internals, so applicants verify current
platform behaviour themselves rather than scoping against claims in this
document that could be wrong or go stale.
logos-co/lez-multisig is referenced as prior art only. Its architecture is
incompatible with private accounts, so it is a reference for the public path
and does not drive design decisions here.
Frontmatter dependency is LP-0002 only. That prize is open and unclaimed,
and its anonymous-approval design differs from this RFP's attributed
approvals (R.1), so it is adjacent work rather than a foundation.
Threshold cryptography (FROST-style) is out of scope; it remains in the
appendix as ecosystem context.

🤖 Generated with Claude Code

- 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

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) <noreply@anthropic.com>

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 <noreply@anthropic.com>

- 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

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

Also drop references to platform constraints the RFP no longer describes from the phased-proposal note. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

fryorcraken · 2026-08-07T03:51:13Z

Related: logos-co/ecosystem#121

fryorcraken force-pushed the rfp/multisig branch from 90847d6 to 96550ee Compare July 8, 2026 03:05

fryorcraken commented Aug 3, 2026

View reviewed changes

fryorcraken added a commit that referenced this pull request Aug 3, 2026

RFP-005: address PR #113 review

253a527

fryorcraken commented Aug 3, 2026

View reviewed changes

fryorcraken commented Aug 5, 2026

View reviewed changes