Plenum

A Privacy-First Multisig Wallet
(That Normal People Can Actually Use)

Working draft · June 2026 · PlenumWallet.com

Abstract¶

Plenum is a multisig wallet for Monero, built around one goal: make privacy multisig usable by normal people, not just by experts. The technology exists. Monero has had multisig for years, yet almost nobody uses it, because setup means trading rounds of cryptographic blobs by hand, getting everyone online at once, and never making a mistake. Backing it up properly is just as hostile to normal users, since the recovery material is not a simple seed phrase. These are walls only experts get over. Plenum removes them: ready-to-use multisig out of the box, automated coordination, and backups that survive a lost device, while keeping the on-chain activity and the coordination metadata hidden.

Contents¶

• 1. Motivation
• 2. Core Features
• 3. System overview
  • 3.1 The group channel
  • 3.2 Access control
• 4. Transport and privacy
  • 4.1 Transport and messaging
  • 4.2 Cryptographic building blocks
  • 4.3 Anonymity network: Tor or Nym
  • 4.4 Delivery substrate: Nostr relays as a flood bus
  • 4.5 Identity, addressing, and rendezvous
• 5. Forming a group
  • 5.1 Initial setup: the master and the setup ceremony
  • 5.2 Onboarding and invitation
• 6. Backup and recovery
  • 6.1 Backup strategy
  • 6.2 Restore workflow
  • 6.3 Recovery UX
• 7. Operational properties
  • 7.1 Group size and performance
  • 7.2 Spam and abuse resistance
  • 7.3 Client surface
• Appendix A: Message schema
• Appendix B: Transport integration
• Appendix C: Threat model

1. Motivation¶↑

Monero has had m-of-n multisig for years, but almost nobody uses it. The problem is not the cryptography, it is usability: setup means several manual rounds of swapping key-exchange blobs, everyone online at the same time, long hex copied without error, and one mistake forces a restart. So the feature sits unused while the need (shared treasuries, group custody, escrow) goes unmet.

On transparent chains, mainstream wallets turned shared custody into a click-through commodity, but everything they do is public on-chain forever. That leaves a gap nobody fills: multisig that is both usable and private. Plenum fills it, with the usability of those wallets and the privacy of Monero.

2. Core Features¶↑

The mainstream multisig wallets serve the transparent smart-contract world. Plenum is the counterpart for Monero: multisig and shared custody that are ready to use, without every step being visible on-chain or in cleartext.

1. Usable m-of-n Monero multisig. Shared custody out of the box, without the user wiring up the crypto layer. Monero first because it is the largest privacy market, and threshold signing for it is now practical (4.2).
2. Automated setup ceremony. A two-round FROST distributed key generation runs automatically, coordinated by a one-time master (a bootstrap role only, no lasting privilege; the group is leaderless afterward) instead of hand-swapping message blobs.
3. Privacy by default. Both the on-chain activity and the coordination metadata stay hidden, unlike the transparent-chain incumbents where every transaction, signer, and threshold is public on-chain.
4. Anonymity-network transport. All messaging is encrypted with MLS (Messaging Layer Security, RFC 9420: the IETF standard for end-to-end encrypted group messaging, with forward secrecy, authenticated membership, and a transport-agnostic design), delivered through public Nostr relays as a dumb store-and-forward bus (4.4) and reached over Tor or Nym, the member's own choice, with no plain-clearnet path. Nostr is storage, not identity.
5. Group channel. Each multisig gets one MLS group serving three roles: social chat, coordination and spend approval, and distributed backup with store-and-forward for offline members.
6. Redundant encrypted backup. One encrypted blob, replicated to three destinations: locally, off-site on S3-compatible stores (ciphertext-only), and with the other group members. Only the user's own seed opens it.
7. Self-service recovery. If a device is lost, the user restores the wallet from any surviving copy of the backup using their own seed. The seed derives both the user's identity and the key the backup is encrypted under, so it reconstitutes everything without other members having to participate.
8. Fully open source, end to end. No proprietary components; a self-custody privacy wallet must be auditable. The building blocks are already free and open (an MLS implementation, Tor/Nym, monero-serai and the FROST threshold-signing libraries). Plenum is licensed GPL-3.0, which also satisfies the copyleft of the linked Nym code.

3. System overview¶↑

Plenum's architecture rests on one construct, the group channel, and one membership rule. This section defines both; the later sections build on them.

3.1 The group channel¶↑

Every multisig group gets its own group channel. From the user's point of view it is always "the group has a chat." Technically it is one MLS group running over the anonymity-network transport.

The channel serves three roles at once:

1. Social space. By default a chat room where the members can simply talk. Not only machine coordination, but a real group chat for the people behind the wallet. This lowers the barrier and keeps the group active, which also makes it a more robust backup network.

2. Coordination. Wallets and users exchange setup rounds, signature collection, spend proposals, and notifications ("your signature is needed"). The interactive multisig setup messages and the approval of each spend flow through here, in the same place as the chat.

3. Distributed backup and offline store. Each member stores its encrypted backup blob with the other members over the same channel, and holds the others' blobs in return. The blobs are ciphertext to everyone but their owner, so this is redundant storage, not shared access: a fellow member can hand your backup back to you but cannot open it. If a member is offline, the others hold the data destined for it (store and forward) where it makes sense, and on reconnect it receives the queued messages and updates. Nobody has to be online at the same time.

3.2 Access control¶↑

For a Monero multisig the membership rule is simple: membership equals "you are one of the n signers." A static list that changes only when the multisig is set up again. The MLS group mirrors the signers exactly: the signer set and the channel membership are one and the same.

When a member leaves or is replaced (which means re-running the FROST setup, 5.1), MLS forward secrecy applies: the group re-keys, so the former member cannot read future messages.

4. Transport and privacy¶↑

Everything the group sends is an MLS-encrypted payload, delivered through public Nostr relays used as a dumb store-and-forward bus (4.4), so no member has to host a reachable service: each client only connects out to relays. Each client reaches those relays over an anonymity network, Tor or Nym, that hides its IP; there is no plain-clearnet path. This section covers that anonymity choice, the cryptography under it, the relay substrate, and how members find one another.

4.1 Transport and messaging¶↑

Plenum has a single class of transport: an MLS-encrypted payload delivered over public Nostr relays (4.4) and reached over an anonymity network. There is no public cleartext path and no broadcast. Everything (setup, coordination, spend approval, backups) is end-to-end encrypted by MLS, the relays see only opaque ciphertext posted under throwaway keys, and the anonymity layer (Tor or Nym, 4.3) hides each member's IP.

MLS is transport-agnostic, so the same encrypted group runs over either network. See 4.3 for what Tor and Nym each protect and where each one's protection ends.

4.2 Cryptographic building blocks¶↑

• MLS (RFC 9420): IETF standard, audited, log-scaling group keys. Transport-agnostic, so the same group runs over either anonymity network.
• Use a maintained MLS implementation (for example OpenMLS), not a chat stack that hard-binds the group to one network.
• Provides authenticity (the sender is cryptographically proven, which protects against key substitution during the setup ceremony) plus end-to-end encryption plus store and forward.

For the wallet itself, Plenum uses FROST (the IETF threshold-Schnorr scheme) applied to Monero's CLSAG, via a maintained implementation such as modular-frost, with monero-serai for building and signing the transactions. FROST gives true m-of-n threshold signing in which every signer holds a single secret share and the distributed key generation is a fixed two-round exchange, avoiding the combinatorial key blow-up and the N-M+1 round count of Monero's native multisig. These Monero-side libraries are young and not yet fully audited, a real and stated risk for a wallet that holds funds.

Why a plain MLS library rather than an MLS-over-Nostr SDK. Existing MLS messengers bundle the protocol with a transport binding. An MLS-over-Nostr SDK wraps the same OpenMLS core, then adds stable Nostr-pubkey identities, key-package discovery by pubkey, and addressed events. That binding is exactly the metadata pattern Plenum avoids: a persistent pubkey links every action to one long-lived identity, and the setup rounds form a recognizable fingerprint. Plenum's delivery (4.4) does the opposite, with ephemeral keys and flood plus trial-decryption, and it keeps the network choice open (Tor or Nym, 4.3). So Plenum reuses the MLS engine (OpenMLS) directly and supplies its own identity, delivery, and transport layers, rather than inheriting a chat SDK's network coupling. Reusing such an SDK would mean adopting the very identity and delivery model the design rejects.

4.3 Anonymity network: Tor or Nym¶↑

The connection to the relays must be anonymized; otherwise a relay would see each member's IP. Every member reaches the relays over one of two networks, an individual choice, with no plain-clearnet option:

• Tor. Hides the member's IP behind an onion circuit; free, mature, large anonymity set. Tor does not mix traffic timing, so a global passive adversary watching both ends can still attempt to correlate that member's flow, and through the synchronized signing rounds, the timing of a spend. Tor protects location, not timing.
• Nym. A real mixnet: cross-user mixing breaks that flow correlation, which is what Tor cannot do. The cost is a smaller, younger network and a paid, token-based bandwidth model.

The choice is per member, not group-wide, and it chiefly affects the member who makes it: someone on Tor accepts weaker timing protection for their own flow, while someone on Nym buys protection against a global passive adversary. The client always routes over one of the two; it offers no cleartext path. Concrete library and wiring details are in Appendix B.

4.4 Delivery substrate: Nostr relays as a flood bus¶↑

Delivery reuses existing Nostr relays as a dumb flood-and-store bus, which solves both message delivery and cold-start rendezvous without Plenum hosting any infrastructure. The practical win is that no member has to host a reachable service: every client only connects out to public relays, the same posture as any client, and the relays hold messages for offline members and act as the rendezvous point.

It is viable only with two modifications that close Nostr's normal metadata leaks:

• Ephemeral keys. Every message is posted under a fresh throwaway key, so a relay cannot aggregate events by sender. Nostr's native discovery-by-stable-pubkey is lost, which Plenum does not want anyway.
• Flood plus trial-decryption. Messages go to a shared rendezvous tag; every member pulls the tag and trial-decrypts, so the recipient is never named. At group scale (n = 5 to 12) the trial-decrypt cost is trivial.

What it does not buy: it does not remove the need for the anonymity layer. The relay still sees the connecting IP; only Tor or Nym hides that (4.3). Flood and trial-decryption protect the application layer (sender, recipient, content), not the network layer.

The anonymity-network choice stays per member here too: the relay only ever sees an inbound connection, so the IP it sees is whatever network the connecting member used, and each member's Tor-or-Nym choice (4.3) protects that member's own connection. The relays never receive a cleartext connection.

The trade-off of leaning on public relays is a dependency on relay liveness, rate limits, and censorship, plus the trial-decrypt overhead. All are mitigated by using several relays at once.

4.5 Identity, addressing, and rendezvous¶↑

Identity. A member's identity is a long-term MLS credential keypair, derived deterministically from the user's seed rather than stored as an independent secret, so the seed alone regenerates it. This is the member_id used throughout, and it maps to the member's Monero signer position established during setup (5.1). There is no account, no external directory, and no separate network identity: the same key authenticates the member across setup, coordination, and backup. Losing the seed is equivalent to losing the wallet material and is handled by restore (6.2).

Addressing. There is no direct addressing: members never dial one another. They meet at the group's shared relay tag, posting under ephemeral keys and pulling plus trial-decrypting (4.4). The relays are the rendezvous, so no address book and no per-member transport address exist.

Rendezvous after a full outage. Even if every member was offline for a long time, no stored address is needed to regroup, because the meeting point is derived from the shared group secret rather than from anything that can go stale:

rendezvous_tag = KDF(group_secret, time_epoch)

Every member independently computes the same tag (the group secret is in everyone's backup) and resumes posting and pulling there. The tag rotates with the time epoch so an observer cannot link a fixed meeting point to the group. A DHT keyed on the same tag is an equivalent substrate.

Backstop. The shared on-chain Monero multisig address is a permanent anchor that every member can re-derive from backup. If even the rendezvous substrate fails, members fall back to out-of-band contact, the same channel used for the initial invite (5.1).

5. Forming a group¶↑

A group comes into being through a one-time, coordinated ceremony. This section covers how it is set up and how the members are invited and verified.

5.1 Initial setup: the master and the setup ceremony¶↑

Creating a group is a one-time ceremony coordinated by a master (the initiator), whoever decides to start a wallet and pulls the others in. The master chooses the parameters (m-of-n and who the members are), creates the MLS group, invites each member, and collects their MLS KeyPackages. He then drives the FROST distributed key generation (DKG).

The FROST key generation. The wallet is built with a FROST distributed key generation (DKG): every member generates their secret share locally, it never leaves their device, and the group public key, and the Monero address derived from it, is deterministic from all members' contributions. The DKG is a fixed two-round exchange for any m-of-n:

1. commit. Each member publishes a commitment to its contribution.
2. share. Each member distributes verifiable shares against those commitments; every member verifies them and derives the identical group key.

This is two rounds regardless of the threshold, and each signer ends with a single secret share rather than the combinatorial set Monero's native multisig would require (7.1).

The master's job is sequencing and relay, nothing more. Each round is a barrier: the master waits until all N members have submitted that round's payload, then relays the bundle and opens the next round. Nobody advances early. The payloads travel as a dedicated "setup round" message type through the group channel, and because every member sees the same broadcast, no member can send different data to different peers (no equivocation). The master never sees any secret share; each share is generated inside its owner's client.

Final address confirmation. When the wallets report ready, every member independently reports the resulting multisig address. The ceremony is valid only when all N report the identical address. A mismatch means stale data or tampering, and the ceremony aborts. Combined with MLS sender authentication (which prevents substituting a member's blob), this is what makes a malicious or buggy master detectable rather than dangerous.

Stalls and dropouts. There is no hard timeout: setup is a deliberate, coordinated act, so a member who is slow to respond is simply reminded and re-invited by the master, not timed out. A permanent dropout forces a restart of the DKG: a key generation cannot swap a participant mid-flow, so if a member leaves before completion the master aborts and re-runs it with the replacement set. There is no partial resume, but the DKG is only two rounds, so a restart is cheap.

The master is a bootstrap role, not a permanent authority. Once the ceremony completes he is one of the n signers with no extra power: he cannot spend alone, cannot evict anyone, and cannot read more than any other member. He holds no special key afterward; the group is leaderless and symmetric. During the ceremony the master also serves as the initial delivery point (he is online and reachable by definition), which is where KeyPackages and round messages flow before the group is fully established.

5.2 Onboarding and invitation¶↑

A group is created by its initiator, the same person who acts as the bootstrap master (5.1). In the client they choose the threshold (m-of-n) and the member set, which creates the MLS group.

Invitations are deliberately out-of-band. Plenum has no directory and no public registration, so the trust that a given person belongs in the group must come from outside the system: the initiator reaches each prospective member over a channel they already trust (in person, an existing secure messenger) and passes a bootstrap invite. The invite carries only what is needed to reach the ceremony, a group/ceremony identifier and the rendezvous coordinates for the master's delivery point (5.1, 4.5). It is not a credential and grants nothing on its own; it just tells the client where to show up.

On accepting, each invited member's client generates its long-term MLS credential (its member_id, 4.5) and a KeyPackage locally, and returns the KeyPackage to the master, who adds it to the MLS group through the MLS Add and Welcome handshake. From there the setup ceremony (5.1) runs.

Verification. Two layers guard against the master adding the wrong key for a member, whether by mistake or to slip in an impostor. First, members compare their MLS credential fingerprints over the same out-of-band channel used for the invite, the standard way to bind a key to a real person. Second, the all-N address-confirmation gate (5.1) is a backstop: a substituted or wrong member key changes the resulting multisig address, so the ceremony completes only when all N independently report the identical address. A tampered member set therefore fails closed instead of producing a usable wallet.

6. Backup and recovery¶↑

Multisig is the hard case for backup, because the key material is not a normal seed phrase. This section covers how Plenum backs a wallet up, how it is restored, and how the interface keeps the user from misunderstanding either.

6.1 Backup strategy¶↑

Goal: every wallet is recoverable from a backup the user controls. Monero single-sig is easy; Monero multisig is the hard case, and that is where Plenum supplies its own backup layer.

Two cases:

1. Monero single-sig: Polyseed (or the legacy 25-word seed) is enough; everything derives from the seed. Nothing special to do.

2. Monero multisig (the critical case): the key material is not derivable from the normal 25-word seed. Each participant holds a FROST key share, generated during the DKG. For a 3-of-5, at most 2 losses are tolerable. A normal seed phrase does not restore a threshold wallet, which is exactly why ordinary users lose funds.

   Here Plenum supplies its own backup layer. The backup is a single encrypted blob: the complete wallet state including the member's FROST key share and personal data (address labels and the like), encrypted client-side before it ever leaves the device under a key derived from the user's own seed. The seed is the single root secret on the user's side: it derives the user's MLS identity (4.5) and the key that encrypts this blob. The FROST share itself is produced in the DKG, not derived from the seed, so it lives inside the blob; the seed opens any surviving copy to recover it. That one blob is replicated to three kinds of destination for redundancy, and the user can enable any or all of them:

   • Local (always on). The blob lives with the user, on their own hardware and storage. This is the baseline and depends on nothing but the user's own seed.
   • S3-compatible remote stores (off-site). One or more S3-compatible endpoints (self-hosted MinIO, a VPS, or a commercial bucket). The operator only ever sees ciphertext, so an untrusted or commercial bucket is safe. Multiple endpoints can run at once.
   • The other group members (over the channel). Each member also stores a copy of every other member's blob, with store-and-forward holding it for anyone offline. The members see ciphertext only, so this is redundant off-device storage, not shared access.

   All three hold the same ciphertext, which only the user's own seed can open. The model is durability through redundancy: a destroyed device is covered by the off-site and member-held copies, and restoring the wallet needs only the user's own seed plus any surviving copy (the FROST key share inside the blob then restores the wallet non-interactively, see restore). It does not protect against a user losing their seed; that is out of scope by design.

   Membership change means a new, independent group. Although FROST supports resharing a key to a new signer set, Plenum deliberately does not use it: there is no in-place edit of the signer set and no migration path between groups. Changing who signs means the users create a brand-new wallet through a fresh DKG (5.1): a new MLS group, new keys, new backups, with no protocol-level link to the old one. Whether and how funds move from the old wallet to the new one is an ordinary spend the users perform themselves while the old threshold still holds; Plenum does not automate it and records no relationship between the two groups. The old group and its backups simply become defunct. Old blobs are ciphertext only their owner can open and back up a wallet the users have emptied, so they are harmless whether kept or not; each user deletes their own local and S3 copies, and lets the group go, if and when they choose. There is deliberately no epoch chain or pointer tying a new group to a previous one.

6.2 Restore workflow¶↑

Restore mirrors setup. Three cases, by severity:

1. Member lost a device, still has their seed. The member fetches their encrypted blob from whichever copy survived (the local one, an S3 store, or a fellow member over the channel) and decrypts it with the key derived from their seed. Restore is non-interactive from the FROST key share inside, so no other member, and no master, has to participate in the decryption. The member then re-joins the MLS group with a fresh KeyPackage and the group re-keys.

2. Member lost their seed too: that member's share is gone. Every copy of the blob is now unopenable, so this member cannot recover their own key material. The wallet's funds are still safe as long as the threshold of other members survives. To restore redundancy, the surviving signers re-run the DKG (5.1) to form a new group (dropping the lost member or onboarding a replacement) and sweep the funds across.

3. Catastrophic loss beyond tolerance: funds frozen. If more signers lose their key material than the threshold tolerates (for example more than 2 in a 3-of-5), the funds cannot be moved at all, because sweeping to a new multisig itself needs the old threshold. This is the hard limit of m-of-n; Plenum cannot work around it. The mitigation is the redundant three-destination backup above: it makes a single member's total loss recoverable and reduces the chance that enough members lose their material simultaneously to break the threshold.

Master vs no-master. Restoring access to an existing wallet (cases 1 and 2) never needs a master. Only rebuilding the multisig itself (case 3, with changed membership) re-invokes the master-coordinated ceremony. So the privileged-looking coordination reappears only when the group structure genuinely changes, never for ordinary recovery.

6.3 Recovery UX¶↑

The backup model (6.1) only protects the user if they grasp two facts, so the interface makes both unmistakable instead of burying them in settings.

First, only the user's own seed opens the backup. The seed is the single root: it derives both the user's identity and the key the blob is encrypted under (6.1). Any local password the client offers is only an optional lock on the running app, may be left empty, never leaves the device, and is no part of the backup encryption or recovery; losing it costs nothing as long as the seed survives. The three destinations (local, off-site S3, fellow members) all hold the same ciphertext, and the client presents them as redundancy, not as custodians: it states plainly that members and remote stores keep a copy they cannot read, so the user never mistakes "my backup is with the group" for "the group can recover it for me." At setup the client shows the seed as the one thing the user must record themselves, noting that it alone reconstitutes the wallet, the identity, and all personal data, and that the FROST key share it protects is what restores a threshold wallet where a normal 25-word seed cannot.

Second, losing the seed is unrecoverable, and the interface says so at the moment it is set, not in fine print afterward. The redundancy across destinations is framed as protection against a lost device, not against a forgotten secret.

Restore presents the surviving copies it can find (the local one, each configured S3 store, each reachable member) and lets the user pull from any of them, then decrypt locally with their seed. The flow mirrors restore (6.2) and, in the common case, never asks another member to take part.

7. Operational properties¶↑

Three cross-cutting properties: how the design scales, how it resists abuse, and what the user actually runs.

7.1 Group size and performance¶↑

Neither layer imposes a combinatorial cost. MLS/TreeKEM scales logarithmically: adding, removing, or updating a member is an O(log n) operation in message size, so the encryption layer would handle hundreds of members without strain. FROST is t-of-n with a single secret share per signer and a fixed two-round DKG regardless of the threshold (5.1), so it has none of the blow-up that Monero's native multisig suffers, where a balanced m-of-n would hand each signer C(N - 1, M - 1) key shares (6 at 3-of-5, 70 at 5-of-9, 252 at 6-of-11). Choosing FROST is what removes that ceiling.

Group size is therefore a usability and trust choice, not a cryptographic one. A Plenum group is a treasury's signer set, so it stays small (typically 2-of-3 to about 3-of-5) because that is what shared custody looks like, not because larger or balanced thresholds would be expensive. MLS re-keying happens only when the signer set changes (6.1); the higher-frequency traffic is the social room, trivial at this scale. The backup's size is dominated by the wallet state (outputs, key images, labels), which grows with usage rather than with the number of signers, since each signer stores just one FROST share. Performance is not a limiting factor.

7.2 Spam and abuse resistance¶↑

A Plenum group is closed, which removes most of the surface. Membership equals the n signers (3.2), every message is sender-authenticated by MLS, and there is no public join endpoint: invitations are out-of-band (5.1) and the master only accepts KeyPackages from members it invited. An outsider therefore cannot post to the social room, the coordination channel, or the backup store at all. A member who floods or misbehaves is not a cryptographic problem but a social one: they are one of the signers, and the remedy is to re-run setup without them (6.1), the same action as any membership change.

The one shared surface an outsider can reach is the delivery substrate itself. On the relay/flood-bus path (4.4) anyone can post to a rendezvous tag, which costs members a trial-decryption. This is bounded by three things: a proof-of-work stamp required per posted message, which makes bulk flooding expensive for the sender, the relays' own rate limits, and the fact that trial-decryption at group scale is cheap regardless (4.4). Per-member quotas on the store-and-forward layer cap how much any one party can deposit. None of this is novel; it is the standard closed-group plus work-gated-substrate model, and it holds because Plenum never exposes an open, unauthenticated endpoint.

7.3 Client surface¶↑

Plenum ships as a desktop wallet with a graphical interface as the primary client. The same application also runs in a headless mode that exposes two programmatic interfaces: a REST API and an MCP API. The GUI covers the ordinary human user (create a group, approve a spend, manage backups); the headless mode lets the wallet be driven without a screen, by a script, a remote operator, or an AI agent acting under human approval. Both modes are the same binary over the same wallet core and group channel, so a headless instance is a full participant in the multisig and the MLS group, not a reduced client.

A mobile wallet for Android follows later, after the desktop client ships; it is the second phase, not part of the first release. iOS is out of scope: its sideloading and background-networking restrictions are hostile to an anonymity-network wallet, and the platform's review and distribution model conflicts with the project's free-software stance. Android allows direct distribution (APK, F-Droid) and the background connectivity the transport needs.

All clients are dedicated Plenum applications built on a maintained MLS implementation (4.2), not a fork of an existing chat client.

Appendix A: Message schema¶↑

Two classes of message travel in a group. The first is MLS handshake, provided by the MLS protocol itself; Plenum does not define it, only uses it. The second is Plenum application messages, carried as MLS application payloads (already end-to-end encrypted and sender-authenticated by MLS).

MLS handshake (from the protocol, listed for completeness):

• KeyPackage - a member's published join material, consumed by an Add.
• Add / Remove / Update proposals and the Commit that applies them - membership and key rotation.
• Welcome - brings a freshly added member into the current epoch.

Common envelope (every Plenum application message):

• type - one of the types below.
• version - schema version integer.
• sender - not a self-declared field; the sender is the authenticated MLS identity, so it cannot be forged or impersonated.
• No wall-clock timestamp is carried by default; ordering is per the MLS/transport layer, so a precise client clock is deliberately not exposed.

Plenum application message types:

member_id is the long-term MLS credential key (4.5), which maps to the member's Monero signer position from setup. Ciphertext in backup.blob is opaque to every member but the owner, consistent with the backup model in 6.1.

Appendix B: Transport integration¶↑

Each member reaches the public Nostr relays (4.4) over one anonymity network, Tor or Nym, chosen per member (4.3). Either way the client only connects out; nothing is hosted.

• Tor. An embedded Tor client (for example arti) routes the outbound relay connections through onion circuits, avoiding a dependency on a system tor daemon. No onion service is hosted.
• Nym. The Nym mixnet SDK carries the outbound traffic as Sphinx packets through the mixnet, which provides cross-user mixing.

Reliability notes: the Nym path is younger, higher-latency, and needs paid bandwidth credentials; both paths lean on relay availability, smoothed by using several relays and the store-and-forward the relays provide.

Appendix C: Threat model¶↑

This consolidates the adversaries named across the document and states, per adversary, what Plenum protects against and what it does not. It is a design-time threat model, not a substitute for an independent security audit.

Adversaries and coverage¶

• Nosy relay or single network observer. Sees an inbound connection and the timing and volume of traffic from one vantage point. Content is protected by MLS end-to-end encryption; the connecting IP by Tor or Nym (4.3); sender and recipient by ephemeral keys plus flood and trial-decryption (4.4). This adversary learns little of value.
• Global passive adversary. Watches many vantage points at once and correlates a single flow end to end. Defended only by Nym, whose real cross-user mixing breaks flow confirmation. A member on Tor is not protected against this adversary: Tor hides location but does not mix timing, so that member's flow, and through the synchronized signing rounds the timing of a spend, can be correlated. This is the accepted ceiling of the Tor choice; a member who needs the protection uses Nym (4.3).
• Chain-timing correlator. Tries to link the timing of group coordination to a Monero transaction appearing on-chain. Nym's mixing breaks the correlation; Tor does not, so a Tor member remains exposed to it.
• Malicious or buggy master. Could try to equivocate during setup or substitute a member's key. Defended by MLS sender authentication (every member sees the same authenticated broadcast, so no equivocation) and the all-N address-confirmation gate (a substituted key changes the resulting address, so the ceremony aborts). The master holds no key and gains no lasting power (5.1).
• Malicious member. Is an authenticated signer, so they cannot exceed the threshold, cannot spend alone, and cannot open another member's backup (ciphertext only). They can leak the group's existence or content out of band, or flood the substrate. The remedy is social: re-run setup without them (6.1, 7.2).
• Compromised member device. Sees that member's own seed, keys, and plaintext. This is out of scope (endpoint security), equivalent to that member losing their seed: it is their own exposure, the funds remain safe while the threshold of other members holds, and MLS forward secrecy limits past content once the group re-keys.
• Untrusted backup store (S3 or fellow member). Holds ciphertext only, encrypted under a key derived from the owner's seed (6.1). It sees blob size and update cadence but cannot open the blob.

The metadata leak the delivery design avoids¶

If delivery used stable identities and addressed messages (the naive substrate), a relay or observer would build a map of the group without decrypting anything. Plenum's delivery (4.4) is built to deny each line of that map.

Standing assumptions¶

• Anonymity is client-bundled, not enforced. The client ships both Tor and Nym and always routes over one of them, with no plain-clearnet option; but there is no way to cryptographically prove what network another member's machine actually used. The residual risk is a member running a tampered client that connects in the clear or leaks its own IP. That is out of scope (like losing one's seed): it is that member's own exposure, unobservable by the others, and the standard model for every privacy tool.
• Endpoint security is out of scope. A member's own device, seed, and client integrity are assumed; Plenum defends the group and the network, not a compromised endpoint.

Residual risks, stated plainly¶

• A member on Tor is exposed to a global passive adversary (flow and spend-timing correlation); the mitigation is for that member to use Nym (4.3).
• A member running a tampered client can connect in the clear or leak their own IP; unobservable by the others and out of scope.
• Leaning on public relays brings a dependency on relay liveness, rate-limiting, and censorship (4.4).