RFP-005: Multisig and Coordination

[fryorcraken]

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

[fryorcraken]

Related: logos-co/ecosystem#121

[vpavlin]

Not on this - we need to consider how to reliably and verifiably update the registry - IDL (needed for decoding) has no provable tie to the program (i.e. I can upload fake IDL to the program which will decode as something safe, but on actual execution the program instruction decoding will do something completely different). I do not have solution, but wanted to point it out

[fryorcraken]

Will add mention. But I expect code to be provided, so that one can verify bytecode and IDL.

[vpavlin]

Transfers of a native token or any token? Because if it is any token then it would have to be bound to the token program Id, but there could be other token program implementations (or updated version). And if it is "any token program" then the question is how to limit this only for tokens and disallow execution of other instructions on other programs:)

[vpavlin]

AFAIU we do not have any global "Logos Identity" and Logos chat identities/keys have not relation to LEZ accounts, so not sure if it is reasonably possible to automatically create a chat room for multi-sig members

[fryorcraken]

so not sure if it is reasonably possible to automatically create a chat room for multi-sig members

"automatically" can be interpreted here and may mean some "invite/accept" action if needed. @jazzz wdyt?

[jazzz]

"Automatically" is the potentially scary word here - I'm assuming thats aligning closer with "Given a multisig, a chat room can be created mechanically".

@vpavlin is right to point out the Identity binding issue between λ-Accounts and LEZ-Accounts. It's currently not defined. Thats largely depends on the logos-co/anoncomms-pm#71 - which is in progress and will result in more information.

This is a good use-case for λ-Accounts to work around, as it brings in an indexing requirement (LEZ-Accounts -> λAccountLogs) and the FURPS need updating

[vpavlin]

do we have a devinition of what a private multisig means? WHen I explored this there is kind of a matrix of things:

1. Private membership
2. Private actions
3. Private funds

And then combination of these

[vpavlin]

What do we mean by SDK here? In theory SDK is an FFI generated by SPEL from the LEZ program...or something else?

[vpavlin]

I do not understand this - the UI will still display a decoded instruction - the key is UI will do that, so what are we trying to emphasize here?

[vpavlin]

I think this is the first time where "off-chain approval collection" is explicitly mentioned - are we saying we only collect approvals off-chain? Should it (or generally any notion of this) defined and required somewhere earlier?

[jazzz]

Overall reads easy, and defines the problem well.

I appreciated that the terms were clearly defined. Most of my questions could be answered with a simple `Ctrl-F'

Some open questions about the interdependence between LEZ and λChat, and a few suggestions on how to improve room requirements so that viability could be properly evuated

[jazzz]

This seems like a hard requirement that spans both the LEZ and Chat domain.

[Sand] Consider adding some +Privacy requirements to the FURPS to make Unlinkability explicit and defined.

"Role separation" unlinkability does not compose. LEZ, and λChat could achieve unlinkability over roles independently but be vulnerable to an intersection attack.

[jazzz]

[?] Is there a data binding requirement here?

It seems like the coordination channel is a party of the the MultiSig process, and may need to have functional requirements. Human deliberation requires Confidentiality+data Integrity which is defined by λChat::GroupV*. However I'm curious if Machine coordination relies on any trust assumptions or a 'data veracity' property.

[jazzz]

... what a removed member can still observe ...

[Sand] This requirement could be expressed clearer. Currently I'm uncertain what specifically needs to be defined and how that set could be bounded.

As worded I understand this to be "You MUST list/document all information a removed program::member can see in room, until it is removed from the room"

λChat state synchronization between members itself is eventually consistent. A Removed chat::member can see all the messages sent by Chat::members who have not seen the state update.

This requirement reads to me as a Tautology of sorts: If everyone knew it the program::member was removed from the program, it would also be removed from the room and they would be synchronized. If a member doesn't know how the change has occured, and operate as normal.