Most Monero users never need multisig. That’s the honest starting point, because the setup is fiddly, every spend needs coordination, and one careless mistake during the key exchange can strand funds permanently. But for shared custody, treasury funds, escrow and inheritance planning, multisig is the only clean answer, and Monero has supported it in the official CLI and GUI wallets for years.
here’s what multisig actually does, how the setup rounds work, and where the failure points are.
What multisig means
In a normal wallet, one person holds the spend key and one person can spend. Multisig replaces that with shared control: the spending responsibility is split across N wallets, and a transaction needs some threshold of them to sign before it can be broadcast.
The common shapes:
- 2-of-3: three participants, any two can spend. Survives one lost or unavailable participant.
- 2-of-2: two participants, both required. Neither can move funds alone, and if either party disappears, the funds are stuck.
- N-of-M generally, within the limits the wallets support.
On-chain, a multisig Monero transaction is indistinguishable from any other transaction. The same ring signatures protect the signers, the same one-time addresses protect the destination, and an outside observer can’t tell that a shared wallet was involved at all. That’s a real advantage over Bitcoin-style multisig, where the script structure is visible to anyone who cares to look.
How the setup actually works
Monero multisig is created through a key exchange, not through a special address format. The sequence in the CLI wallet, which the GUI wizard walks you through, looks like this:
- Every participant runs prepare_multisig in their own wallet and produces a short block of text. That text is their public share of the key material. 2. Everyone sends their block to everyone else, through any channel: chat, email, a shared file. Each participant then runs make_multisig, handing it the shares from the other participants. 3. For most configurations, one more exchange round follows: make_multisig produces new text, everyone swaps it again, and each wallet runs exchange_multisig_keys. After the final round, every wallet displays the same shared address.
The address that appears at the end looks like a normal Monero address. People can pay into it the same way as any other, and nothing about it reveals the multisig arrangement.
The critical detail is the middle step. Until the final exchange round completes, no wallet is fully synced. The exchange messages, those blocks of text, are the only path to reconstructing the shared spend key. If a participant deletes their wallet or loses the exchange messages before the last round finishes, the whole multisig wallet can become unrecoverable, with funds already on the address or without them. Save every exchange message until all wallets show the same address and every participant has their final seed words backed up. Then save the seed words again.
Spending from a multisig wallet
Spending is where multisig costs its convenience tax. One wallet builds the transaction and signs it, which produces a partially signed blob. That blob travels to the other required signers, each of whom signs in turn, and the last signer, holding a fully signed transaction, broadcasts it.
Practical consequences:
- The required signers must be reachable for every spend. A 2-of-3 treasury works when at least two of three people are around.
- The transaction can be relayed by any of the participants. The initiator doesn’t need to be the one who broadcasts, so the person proposing the spend doesn’t need a synced, online daemon.
- Signers see the transaction details before signing, which is the point of the arrangement. Nobody signs blind.
- there’s no partial-spend shortcut. If you want three of four people to approve large spends but one to handle small ones, you can’t encode that in the wallet; you need a policy outside it.
The GUI’s multisig messaging makes the blob-passing mostly automatic between participants who agree to use it. The raw CLI route is entirely manual but works fine over any channel.
When multisig earns its keep
The arrangements where multisig is clearly worth the friction:
- Shared project or community funds, where no single person should be able to walk away with the treasury.
- Escrow, where a neutral third party holds one key of a 2-of-3 arrangement, and the buyer and seller hold the other two. The third party only ever signs alongside one side, never alone.
- Business custody, where two partners both need to see a spend before it happens.
- Inheritance planning, where keys are distributed such that a defined group can act together if the primary holder is gone.
And when it’s the wrong tool: personal savings, where a hardware wallet or a well-backed-up standard wallet does the job with none of the coordination, and any situation where the participants can’t reliably reach each other. The recovery question is decisive, because restoring a multisig wallet means replaying the same key exchange process, with the same message-passing, before the shared address exists again. Backups must include the seed words and the multisig exchange data, per participant.
The angles worth knowing alongside this
Two neighboring topics come up in every multisig discussion. The first is where the change goes when a multisig wallet spends: multisig behaves like any other Monero wallet here, sweeping unused outputs back to a fresh change address the wallet controls, as we described in our piece on change addresses and view tags. The second is proving a payment to a third party without giving them the wallet, which in a shared-custody setting is often done with a view key, and our walkthrough of verifying a transaction with a view key covers the usual dispute pattern.
The short version
Multisig in Monero gives you shared control with on-chain privacy: no observer can see the arrangement, and no single participant can move funds alone. You pay for it with a multi-round key exchange that punishes carelessness before launch, and with a sign-off requirement on every spend for the life of the wallet. If your threat model actually includes a rogue insider or a single point of failure, the setup cost is trivial against what it prevents. If it doesn’t, stay with a standard wallet and keep your backups boring.