Safe multisig
A 2-of-3 Safe, with every transaction field in the signed hash. A delegatecall is shown and refused unless allowed. Settled on chain by the room.
builtEVM
A local-first client on the Logos stack
Do things together, privately.
Muster (v.) — to assemble, as people gathering for a common purpose. Get people into a room, agree on what to do, and do it, without anyone outside the room watching.
Muster coordinates multi-party transactions inside end-to-end encrypted conversations. Pay from a shared account, split a bill, or request XMR. The conversation is the security boundary: who is in the room decides who can read what is being done.
Offsite budget
3 members · epoch 2
AN
Ana — Venue wants the deposit today. Proposing it from the team Safe.
Safe · 2 of 3proposed by Ana
Pay 1.2 ETH to the venue
proposedcollectingexecutablesubmittedfinal
ANAna approved
YOUYou
JOJoe
Re-derived
safeTxHash from the effect you reviewed. It matches; your key may sign.ApproveDecline
Outside the room · what a store node sees
ciphertextcontent topictiming & sizethe proposalwho is in the room
Recorded, not drawn
See it run.
Two people, two Basecamp installs, real transactions on the Sepolia testnet. Nothing here is mocked: the keys are in each person's Logos keystore, every signature is approved in the Logos Signer, and each payment is confirmed by the person it was owed to, from their own read of the chain.
Name what you're doing, then who with
Alice picks Split a bill and pastes Bob's contact link. Bob's Home shows the invitation; he joins, and each puts a name to the other, a name only they see.
Agree in the room, pay from your own wallet
Alice proposes 0.002 ETH. Bob agrees with his room key, then pays his share: the Logos Signer shows the one transaction it will sign. Alice's own read of the chain confirms it, and the split is final on both screens.
Two owners, one Safe they already had
Alice discloses a 2-of-2 Safe; every member's client checks it against the chain. She proposes a payment from it, both owners approve in their Signer, and Bob settles it on-chain.
Who sees what, and how the room got here
Every card answers for itself: which observer learns which field, from the room to anyone reading the chain, and the room's own history, step by step, from the record every member keeps.
Muster 0.3 in Logos Basecamp 0.3.2, recorded on a virtual display and cut for length; waits for the chain are sped up, never removed. The scripts that recorded them are in scripts/demo.
The shape of the product
Start with what you want to do, not with a chat.
A chat app asks who? first. Muster asks what you are doing, and derives the rest: the room, the account, and what each person must bring.
01 · THE SHELL
Who you are, and what you reach
Your keys, your wallets, the plugins you trust, and the infrastructure you point at. RPC endpoints and store nodes are settings — untrusted and chosen by you. No server, no telemetry.
02 · THE INTENTION
Start something
Name what you want to do with a group — pay from a shared account, split a bill, request a payment in XMR. The intention opens the room and asks each person for exactly what it needs.
03 · THE ROOM
Proposals that carry their own proof
Every proposal is a card with its live state. Open it to see the exact bytes you would sign, the domain they bind to, and where each input came from.
The lifecycle is the curriculum
Every step of a transaction, made visible.
Muster's first job is education. It walks people through the whole lifecycle of a multi-party transaction, and at each step answers four questions on screen. The teaching client and the real client are the same client: there is no demo mode.
- draftSomeone writes what the group should do.
- proposedIt enters the encrypted room as a card.
- collectingMembers review the effect and contribute.
- executableThe driver's threshold is met.
- submittedIt leaves the room, onto a chain.
- settlingThe driver says what finality means.
- finalSettled, and rebuilt from the log alone.
- What just happened?The mechanical step, in plain language.
- What does Logos protect here?What stays inside the room, and which property guarantees it.
- Where do others leak?The concrete comparison, at the same step, in a conventional stack.
- What is still open?The gap at this step, named plainly, with what would close it and its real status.
Same step, different stack
Where the information goes.
Coordinating a shared transaction usually means a service in the middle: it holds the proposals, pools the signatures, and sees everything. Muster keeps that work inside the room.
Stage
Muster on Logos
Conventional stacks
Compose & propose
The proposal lives in an end-to-end encrypted conversation. Store nodes see ciphertext.
Proposals sit in a coordination service's database, visible to its operator, often behind a public read API.
Review
You review the effect. Your client re-derives the bytes to sign and refuses on any mismatch.
Signers approve opaque calldata or a hash they cannot rebuild. Blind signing is the norm.
Collect signatures
Signatures travel in the room, bound to environment, account, slot and expiry — worthless anywhere else.
Signatures pool in a central service. Progress, signers and timing are public or visible to the operator.
Submit & settle
The card names what became public and what stayed inside. Finality is described by the driver; a reorg shows as a state change.
The coordination history often becomes linkable in indexers. Finality is assumed; a reorg silently rewrites the UI.
Membership over time
Each change of members re-keys. A new member cannot read what came before they joined.
Chat and signing membership are separate or unmanaged. Departed members keep the full history.
Infrastructure
No server-side state. Store nodes and RPC are untrusted and chosen by you — but untrusted is not blind (see below).
Vendor servers hold application state. Telemetry is on by default.
Illustrative, from the vision. Inside the client, every "Logos protects" claim maps to a requirement and a test that fails if it stops being true, held in a claims registry that CI checks.
Ten invariants
Breaking one is a bug, not a trade-off.
Ten rules the code holds, whatever the tests say. Each has a typed spec with acceptance oracles, and probes that run against the module core.
- Review the effect; sign the materialization.Your client re-derives the bytes from what you reviewed and refuses on mismatch. This check cannot be turned off.
- A signature is worthless anywhere else.Every signing payload commits to environment, account, slot and expiry.
- Plugins never sign.They hold no keys and touch no network. They emit typed blocks only.
- State = reduce(log).Nothing exists that cannot be rebuilt from the log and your keys. Reorder or duplicate events: the state converges.
- Deterministic bytes.The same value always encodes to the same bytes. Every hash is a domain-separated record.
- The core never interprets contributions.Drivers do. Rounds, threshold and finality are described by the driver, never hardcoded.
- Membership epochs are real.Adding a member re-keys forward. They cannot read earlier epochs.
- No server, no telemetry.Store nodes and RPC endpoints are untrusted, configurable infrastructure.
- You speak only for yourself.The client tells a member only what another member disclosed. Inside the room, every approval and decline is named.
- Nothing is signed whose inputs are unaccounted for.Each input to a signature has a recorded origin and log position. If any origin is unknown, signing is refused.
What a room can do today
One room, many ways to agree.
The core is driver-generic. A driver says where the threshold lives — in a contract, in a script, in an aggregate key, in an on-chain vote, or with each person paying their own share — and the room coordinates it.
Bitcoin multisig, through PSBT
P2WSH sortedmulti and taproot multi_a. Sign in the app, or export a PSBT to a signer outside Muster and import what comes back.
builtBitcoin
FROST threshold Schnorr
The room runs the key ceremony and both signing rounds over its log. On chain, the spend is one signature — the same as a single signer's.
builtBitcoinLEZ
LEZ multisig program
Logos's own chain. Each approval is the member's own on-chain vote, read back and confirmed by the room before it counts.
builtLEZ
Split the bill
One person fronted a bill. Each person agrees to their share and pays it from their own wallet; the creditor's client confirms each payment from its own read. Fiat bills convert exactly. With one payer, it is a payment request.
builtETH & ERC-20BitcoinLEZ, privateMonero
Settle up
Net the room's open shares into fewer payments. Every balance is conserved, and every person covered agrees again before anyone pays.
builtsplit families
The atlas lists every multisig family Muster has surveyed — built, candidate, watched and rejected — and every action a person can take, with who acts, what is signed, and who learns what. Open the atlas →
New · XMR in a room
Request XMR. The payee's own wallet confirms it.
Monero is fungible cash, and settlement stays on Monero. Muster covers the rest of the deal: agreeing in a private room, asking for the payment, and confirming it — with no new wallet app, and no custody.
- Agree in the roomThe terms and the request live in the encrypted room. The payee agrees to the request too: their word that the address in it is theirs.
- A fresh subaddressThe payee's own Monero wallet in Basecamp mints a subaddress for this request alone.
- Pay from any walletEach payer pays through a
monero:link or QR code carrying the address and the exact amount — from Cake, Feather, or Basecamp's own wallet. - Their own wallet confirmsThe payment counts when the payee's wallet sees exactly that amount arrive at that subaddress, at 10 confirmations. A payer's "I paid" never decides.
- On chain · Monero's guaranteeNo sender, receiver or amountThe Monero chain shows none of them, and a subaddress cannot be linked to the payee's other addresses. That privacy is Monero's, not Muster's, and the card says so.
- In the room · Muster'sThe deal stays insideThe terms, the memo and the transaction id stay in the encrypted room. The
monero:link carries only the address and the amount. - Keys · none in MusterMuster holds no Monero key and never spendsIt asks the payee's wallet, through the platform's Monero modules, for a subaddress and for its history. Opening the wallet is the wallet app's job, and every payment is sent by the payer's own wallet.
Deal room
2 members · epoch 1
JO
Joe — Terms agreed. Send me the request.
Monero · stagenetrequested by you
Joe pays you 0.25 XMR
proposedcollectingexecutablesubmittedfinal
monero:7…?tx_amount=0.25
Joe says they paid — seen, 4 of 10 confirmations. Only your own wallet confirms it.
Outside the room · what the Monero chain shows
a transactionsenderreceiveramountthe room
Built, on stagenet
- The request, a bill split in XMR, the link and QR code, "I paid", and the rule by which the payee's wallet confirms. Family
monero.split; its seven guarantees are a typed spec, graded 7/7. - Seen on screen in Basecamp 0.3.2: a real stagenet wallet minting the request's subaddress, and the QR code reading back as the link, byte for byte.
- Until a payment is confirmed automatically, the payee can mark it received by hand.
Still ahead
- A live stagenet payment, confirmed by the payee's own wallet at 10 confirmations, end to end. So far that rule is held by tests over a stand-in wallet.
- Paying from Basecamp's own wallet, once the wallet app can review a send another module prepared (an upstream ask).
- Mainnet, behind a gate. A chain-side receipt needs Monero tx proofs upstream.
Monero multisig stays out: upstream calls it experimental, and the platform's wallet does not expose it. Every XMR action is each person paying their own part. The plan: Monero in rooms · the build: the labbook · the spec: derived-exo-dcc.5.
The whole transaction, link by link
All seven links are Muster's to cover.
A transaction between people leaks at seven links: discovery, diligence, negotiation, contracting, ordering, settlement, enforcement. Every one is in Muster's scope, at different stages. Each row says what the code does today; what is planned is named as planned.
Link
Muster today
Ahead
Discovery
A room starts from an invite, not a directory or a lookup. Nothing on a room's topic names its members. The store node still sees that someone asked to join.
Finding counterparties you don't already know, with no platform that learns who looked.
Diligence
Each member's two identities are bound by a signed statement. Members disclose their own accounts, and the client checks them against the chain. It says about a member only what that member disclosed.
Checks on a counterparty beyond what they disclose.
Negotiation
An end-to-end encrypted room with no coordination server. Proposals, declines and chat stay inside it. Adding a member re-keys forward.
Choice blocks, and offer and counter-offer.
Contracting
The client re-derives what it signs and refuses on a mismatch. Every signing payload commits to environment, account, slot and expiry. Signing is refused when any input's origin is unaccountable.
Showing what breaking a commitment would cost the party who could break it (proposed).
Ordering
Submission goes through infrastructure you choose, and the flow view names the RPC provider when a driver uses one. An XMR payer broadcasts through their own wallet and node. Muster can send a room's messages through the Logos mixnet. It is an opt-in setting, built on Logos Delivery 0.3's sender anonymity. It hides which participant sent a message, not who reads a room: reading still asks a store node for the room directly.
Hiding who reads a room. Submission through your own node or a proxy, rail by rail.
Settlement
The intent settles on the chain its driver names, and the card says what that chain reveals. A FROST spend shows one signature; a LEZ private split shows only that private transfers happened; a Safe or Bitcoin multisig is public; on Monero the chain shows no sender, receiver or amount — Monero's guarantee.
More rails.
Enforcement
The card names the rail, and so whose producers settle it. The chain enforces the multisig thresholds. Every room's record exports as a self-verifying proof. A split share — XMR included — counts as paid only when the person owed confirms it, and nothing yet makes anyone pay.
Escrow; swaps (RFP-003); a chain-side XMR receipt, once Monero tx proofs exist upstream.
Muster classifies; it never scores. A link is described by what holds it and whose conduct it still rests on, never by a percentage. The full table, with what each link leaks: explaining Muster, §4c.
The fourth question
What Muster does not hide — yet.
A client that ships a real improvement and names its remaining leak teaches more than one that claims the perfect stack already exists. Each gap names the fix and where that fix actually stands.
Partial
The store node sees the conversation graph
Content is encrypted. But a store node still sees a room's content topic, and the timing and size of what is published and fetched. It never sees who is in the room.
Partly addressed: Muster can send a room's messages through the Logos mixnet. It is an opt-in setting, built on Logos Delivery 0.3's sender anonymity. It hides which participant sent a message, not who reads a room: reading still asks a store node for the room directly.
Partial
Verified reads trust a state root
A verified balance checks a Merkle proof against a state root — which the client fetches from the RPC you configured, and trusts.
The fix: a beacon light-client sidecar that verifies the root itself. Deferred on infrastructure.
Not built
Nothing makes anyone pay their share
A split records who agreed and who paid, truthfully. But no contract holds the money: it is a promise the group can see, not one the chain enforces. An XMR request is the same.
The fix: a split with deposits, each share locked in escrow at agreement.
Explore
Go deeper.
Two references are published here. Both are self-contained pages, and each figure says where its facts came from.
The visionWhy Muster exists, and the honesty rules that bind every surface.
The pipeline and discoveryThe argument, as a post.
The requirementsNormative, with stable ids.
The typed specsEach invariant, with its acceptance oracles.
The labbookTraps found the expensive way.
The client tourRun it yourself, every chain local.
Install from the catalogueEvery step and label, as Basecamp 0.3.2 shows them.
Monero in roomsThe plan for XMR, and what each link can show.
Install
Add Muster's catalogue to Basecamp.
Muster ships its own catalogue for Logos Basecamp. Add it once, then install Muster like any other app; Basecamp resolves every dependency from the official Logos catalogue. The latest release is muster-v0.3.0, published 2026-10-14.
No Basecamp yet? The same release carries an AppImage: Basecamp 0.3.2 with Muster and every module it needs already inside. Download it, chmod +x it, run it, and click M in the sidebar; the steps below are not needed.
Linux x86_64 onlyLogos Basecamp 0.3.2about 650 MB of downloadsunsigned
-
Add the catalogue
In Basecamp, open . Under Add a repository, paste this URL and press Add:
https://raw.githubusercontent.com/corpetty/muster/main/catalog/logos-repo.jsonA Muster entry appears in the list, below Logos Official, enabled.
-
Install Muster
Open Applications, search
muster, and click Muster. In the install dialog, untick Monero Node (local) unless you mean to run your own Monero node — the wallet can use a remote one. Keep the rest, then press Install. -
Open it
Press Launch. Muster opens on Needs you, with a Getting started list; that is where you set up your accounts and chains (first-run runbook). Members of a room should run the same version.
What adding it trusts
Read this before you add the URL.
- It publishes two packages,
muster_moduleandmuster_ui, and nothing else. Basecamp takes the newest version of a package across every catalogue you enable, so a catalogue that listed an official package's name could replace it. Muster's never does; its release script refuses to. - Every dependency comes from the official Logos catalogue, which Basecamp enables by default: Delivery, the LEZ core, the EVM and RLN modules, and the optional Monero wallet modules.
- Nothing is signed. That is true of the official catalogue too. Basecamp checks each download against the hash the catalogue lists, so you get the file it names. Nothing proves who built it.
- Muster runs inside your Basecamp session with no sandbox, like every Basecamp module. Adding a catalogue means trusting its publisher with that.
- Linux x86_64 only. On other platforms Basecamp shows Muster as "Not Available".
The full steps and the known rough edges: install from the catalogue · the catalogue · releases
Where it stands
Real, running, and honest about the rest.
Everything shown is enforced by running code. A Nim core behind a language-neutral contract, and a QML interface, built as Logos modules.
Runs today
- The whole lifecycle in the UI — propose, approve, submit — against a real 2-of-3 Safe.
- Two instances converge over the live Logos network: join, ask, admit, re-key.
- A relaunched member re-enters its rooms and reads them again, its founding epoch included, on Logos Delivery 0.3.2.
- Safe, Bitcoin, FROST and the LEZ multisig program, coordinated from the room.
- Split the bill in ETH, tokens, Bitcoin, privately on the LEZ, and in XMR, where a one-payer split is a payment request (stagenet).
- Muster can send a room's messages through the Logos mixnet. It is an opt-in setting, built on Logos Delivery 0.3's sender anonymity. It hides which participant sent a message, not who reads a room: reading still asks a store node for the room directly.
- An install from Muster's own Basecamp catalogue.
- All ten invariants, each held by probes in the test suite.
Still ahead
- The multi-party runs across two machines: a Safe transaction settled over the live network, and resilience when a member drops mid-collection.
- An XMR payment on stagenet confirmed by the payee's own wallet end to end; paying from Basecamp's own wallet; mainnet.
- The LEZ multisig and a FROST ceremony, run across two instances.
- Every LEZ path live on the v0.3 testnet.
- Hiding who reads a room, and a plugin runtime beyond the sandbox.
As of 2026-10-09 · the current phase is in CLAUDE.md