Multisig, explained

A plain-English guide to shared-key accounts on Bittensor — why they exist, how they work, and how you create a transaction on one.

A normal wallet has one key. Whoever holds that key controls everything — and if it leaks, everything is gone, irreversibly. A multisig ("multi-signature") fixes that by requiring several keys to agree before anything moves. This guide walks through the whole idea in three short steps.

1.Why you'd use one

A single key is a single point of failure — in both directions:

If it's stolen

A compromised laptop, a phished seed phrase, one bad dependency — and an attacker drains the account. There's no undo, no support line, no chargeback.

If it's lost

Lose the one key — dead drive, forgotten phrase — and the funds are frozen forever. Same finality, opposite cause.

A multisig removes that single point of failure. Funds live at an address controlled by a group of keys, and a transaction only goes through once enough of them approve. Concretely, that buys you:

Theft protection. A thief with one key can propose a transfer but can't execute it. The other signers see the pending request and simply never co-sign.
Loss protection. Lose a key and you've lost nothing — the remaining signers can still move the funds to a fresh account.
Shared control. A team treasury where no one person can move money alone. Every payment needs a genuine second (or third) pair of eyes.

The everyday version: a bank vault that needs two managers to each turn their own key at the same time. Neither can open it alone; if one manager quits or loses their key, the others can still get in. No one holds "the vault key" — there isn't one. That's a multisig.

2.How they work — "M-of-N"

A multisig is described by two numbers, written M-of-N:

N = the total number of member keys (the whole group).
M = the threshold — how many of them must approve before anything happens.

A 2-of-3 multisig has three member keys and needs any two of them to sign. A 3-of-5 has five members and needs any three.

Two things are worth knowing about how this works under the hood — both matter in practice:

The address is derived, not created

There's no "create a multisig" button and no key that unlocks it. The address is pure math over the member set plus the threshold: feed in the same keys and the same M, and you always get the same address, on any machine. Nobody holds "the multisig key" because no such key exists — only the members' own individual keys, working together.

One consequence to remember: because the address is the member set plus the threshold, changing either one changes the address. Add a signer, remove a signer, or change 2-of-3 to 3-of-3, and you get a completely different account. To "swap a signer" you create a new multisig and move the funds across.

Picking your numbers is a trade-off

Raising the threshold M makes you harder to attack but easier to lock yourself out of. The gap between N and M is your safety net — how many keys you can lose and still transact.

Setup	Thief needs	Keys you can lose	Good for
2-of-3	2	1	The classic. One rogue or one lost key, no problem.
2-of-4	2	2	Keys spread across places/people; survives two losses.
3-of-5	3	2	Strongest balanced choice for a bigger team treasury.

The trap to avoid: never run N-of-N (like 3-of-3). It has zero safety net — lose a single key and the funds are frozen forever, because you can never again reach the threshold. Always keep at least one spare (N − M ≥ 1).

3.Creating a multisig transaction: public or private

When someone kicks off a multisig transaction, they choose how much of it is visible on the public blockchain while it waits for the other signatures. This is the one real choice you make each time, and it's just a trade-off between transparency and privacy.

Public

The full transaction goes on-chain immediately.

Technically: asMulti. The moment it's opened, everyone can read exactly what's being proposed straight from the chain. Co-signers just look it up and approve — nothing needs to be sent around.

Private

Only a fingerprint of the transaction goes on-chain.

Technically: approveAsMulti with a hash — a one-way fingerprint of the call. The public chain sees "a transaction with this fingerprint is pending" but not what it does, until it actually executes.

What the "hash" is, in plain terms

A hash is a short, unique fingerprint of the transaction. You can compute the fingerprint from the transaction, but you can't work backwards from the fingerprint to the transaction — it's one-way. So in the private flow, the chain only ever sees the fingerprint. The actual transaction has to be handed to the other signers separately (a copy-paste, a link, a shared file).

The golden rule of the private flow: when a co-signer receives the transaction, their tool re-computes its fingerprint and checks it matches the one already on the chain. Match → safe to sign. Mismatch → someone tampered with it, refuse. That check is what makes it safe to pass the transaction around outside the chain. This is the step you never skip.

One subtlety about "private"

Private hides the details of the transaction while it waits — but only if those details aren't guessable. Here's the catch: since anyone can compute a fingerprint from a transaction, an observer who can guess what you're doing can hash their guess and check whether it matches the pending one. So if you always do the exact same thing — say, 50 TAO to the same wallet every Thursday at noon — the "private" version isn't really hidden; a watcher just tries the obvious call and sees it matches. The chain's fingerprint is doing its job; the leak is that your transaction itself is predictable.

Two ways to fix that when your transactions are predictable: (1) add a tiny random note to the transaction (a remark with some random text) — that changes the fingerprint every time, so no one can guess it; and/or (2) use the MEV shield when the transaction finally executes, so it can't be front-run at the moment it goes through. The random note protects the waiting period; the shield protects the execution — two different moments, two different tools.

	Public asMulti	Private approveAsMulti
On the chain while pending	The whole transaction	Only its fingerprint (hash)
Co-signers get the details from…	the chain (automatic)	you, sent separately
Visible to the public before it runs?	Yes	No
Extra step for signers	none	paste in the transaction to verify the fingerprint
Best when	simplest & most transparent — the default	you don't want the pending action public early

Either way, it becomes public in the end. Once the final signer executes, the transaction runs on-chain and is visible to everyone. "Private" only means it's hidden while it's waiting for signatures, not forever. And on both paths, the fingerprint-check is the safety gate — the private path just makes it explicit.

The whole thing in five lines

A multisig is an account controlled by a group of keys, needing M of N to approve any action.
It protects you from both theft (a thief with one key can't act) and loss (a lost key doesn't lock you out).
Its address is derived from the members + threshold — change either and it's a new account.
Each action can be public (whole transaction on-chain) or private (only a fingerprint on-chain, transaction passed around separately).
Before signing, always confirm the transaction's fingerprint matches the chain. That one check is your safety.

Examples

Worked examples from the chain — real multisig operations, decoded, showing exactly what public and private look like on-chain.

Wallet security

Securing a wallet: Ledgers, multisig & proxies — how multisig fits alongside hardware wallets and proxy accounts to protect a treasury.

Bittensor multisig tutorial · plain-English register · source: RaoFoundation/subtensor docs & pallet-multisig. Draft — Taostats internal.

Multisig, explained

1.Why you'd use one

2.How they work — "M-of-N"

The address is derived, not created

Picking your numbers is a trade-off

3.Creating a multisig transaction: public or private

What the "hash" is, in plain terms

One subtlety about "private"

The whole thing in five lines

Related