Security
How M5 Vault actually works
This page explains the mechanism rather than asserting that it is safe. Where there is a limitation or a trade-off, it is stated.
The signing ceremony
What crosses the channel is never a share
Signing is an interactive protocol. Each party computes messages from its own share, sends those messages, and derives the final signature. At no point does either side transmit its share, and at no point does the whole key exist.
Two vault types
You choose who holds the second share
The protocol is the same in both cases. What differs is who the second party is, and therefore what you are trusting.
Fast Vault
The second share is held by M5's co-signer service. It is stored encrypted with AES-256-GCM under a password only you know, and the service cannot use it unless you supply that password with the request.
Trade-off: convenient, and it works with one device — but M5 operates the second party, so signing depends on that service being reachable.
Secure Vault
The second share is held by a second device you control. The ceremony runs between your two devices, with M5 operating only the relay that passes encrypted messages between them.
Trade-off: no dependence on M5 to sign — but you need both of your devices present to approve a transaction.
Plainly stated
What M5 can and cannot do
M5 cannot
- Move your funds. One share cannot sign; a Fast Vault share is also encrypted under your password, which M5 does not hold.
- Reconstruct your key. The protocol never assembles it, so there is nothing on our side to combine.
- Recover your vault for you. This is self-custody — there is no support process that can restore access.
- Read your ceremony traffic. Relay messages are encrypted end to end between the two parties.
You are responsible for
- Keeping your vault backup. Both shares are required to sign; losing your access without a backup means losing the funds.
- Your Fast Vault password. It encrypts the server-held share and is not recoverable by us.
- The security of your devices. A compromised device can ask you to approve a transaction you did not intend.
- What you sign. Approving a malicious transaction is still approving it, whatever the key mechanism.
On the device
Beyond the protocol
Local encryption
Sensitive local storage is encrypted with AES-256. Share material never appears in logs or crash reports.
Isolated signing
Key operations and hardware-wallet communication run in a background process, separated from any page or web content the wallet renders.
Transaction checks
Transactions are decoded and risk-checked before you are asked to approve, and dApp URLs are checked before a connection is opened.
Native implementations
The threshold-signature libraries ship as native modules on Android and iOS rather than as JavaScript.
What we are not claiming
M5wallet has not completed a third-party security audit, and this site does not claim one. It carries no certification, no insurance and no guarantee against loss. The protocol described above is a well-studied construction, but a correct construction implemented in real software is still software. Treat the beta as beta, and do not put in more than you are prepared to lose while it is in testing.
The co-signer service, the relay and the wallet clients are part of the M5 codebase. If you are evaluating this seriously, read the implementation rather than trusting this page.