Sanctum rolls out 2-of-3 multisig protection for app wallets

Sanctum announced on November 5, 2026, that every wallet in its consumer mobile app now requires approval from any two of three keys before a transaction can proceed, extending 2-of-3 multisig protection to retail users on Solana.

The Solana protocol is best known for liquid staking and yield. Sanctum frames the change in product terms: “The pitch is no longer only about growing your assets. It is also about making sure they are still there tomorrow.”

Sanctum App 2.0, launched on October 1, 2026, carried the first references to multisig protection. The full public rollout followed roughly five weeks later.

What does the 2-of-3 setup change for users?

Sanctum divides transaction authority across three locations:

• Device key: Stored on the user’s phone and gated by biometrics.
• Cloud key: Kept in either iCloud or Google Drive.
• Recovery key: Linked to the user’s email and secured through Turnkey.

Any two can approve a transaction. A user who drops a phone in a lake can still reach the funds by combining the cloud and recovery keys.

Operationally, no single compromised location can authorize spending on its own. Losing a phone does not strand assets as long as users retain the cloud and recovery paths. A compromised cloud account likewise cannot authorize transactions unless the attacker also obtains another key. Recovery becomes a three-channel control process rather than restoration of one seed phrase.

The multisig runs on Squads infrastructure. Squads currently protects more than $15 billion across Solana applications, much of it held by DAOs and teams. Sanctum is adapting a control model built for organizations to a single consumer wallet.

The implementation embeds smart-account technology directly into the app. Users receive multisig protection without manually setting up and coordinating a multisig themselves. This removes a configuration burden while retaining the approval structure used for organizational balances.

For users, the main benefit is continuity rather than an increase in staking yield. The design addresses two operational failures that a single seed phrase cannot recover from: a compromised device and an inaccessible one. A broken or stolen phone no longer has to mean a lost wallet when the cloud and recovery paths remain available.

Most self-custody wallets have historically relied on a single private key or seed phrase. Theft can drain those funds; loss can leave them permanently inaccessible. Neither failure alone ends in disaster when two independent keys remain available.

The arrangement also places part of the security burden on outside services. The cloud key depends on Apple or Google account security. The recovery key depends on the user’s email account and Turnkey. An attacker would generally need to compromise two of those three locations at once, a materially higher barrier than stealing one seed phrase.

Users should therefore protect email and cloud accounts as they protect the wallet itself. Strong passwords and two-factor authentication on those accounts now directly protect crypto holdings. Those familiar identity services have become part of the wallet’s security boundary rather than separate conveniences.

A separate layer from protocol governance

Sanctum already uses a 6-of-11 multisig to manage protocol upgrades. That structure governs Sanctum itself, not individual user wallets. The new 2-of-3 system applies to retail users holding their own assets and does not replace the upgrade authority.

Market reaction was muted, with no significant price fluctuations following the update. For Sanctum, the more consequential test is operational: whether stronger recoverability improves trust and attracts users seeking safer staking options.

Because Squads already secures large institutional balances on Solana, Sanctum’s adaptation for individuals may become a template for other protocols. The next structural test is whether other consumer applications begin embedding multisig accounts at the wallet layer, moving security away from user-configured seed phrases and toward application-controlled recovery.