Skip to main content
WalletSuite MPC keeps every wallet self-custodial with no seed phrase. The signing key lives as two shares. You hold one, returned by the SDK as the wallet. The WalletSuite signing service holds the other. Both shares are needed to sign, and the full key is never assembled anywhere. This page walks through who holds what, how a wallet is created, how a transaction gets signed, and why funds stay safe.

​
The parties

Every wallet is split between two parties, and both are needed to sign.
  • You hold the wallet. The SDK returns it to you to store or hand to your end user, and you pass it back on every signing call. See Shares & thresholds.
  • WalletSuite holds the other share. The WalletSuite signing service runs server-side and is fully managed. You never deploy, host, or operate anything. It is reachable at the URL you pass to the client, and https://cosigner.walletsuite.io is the recommended production endpoint.
You cannot sign alone, and WalletSuite cannot sign alone. It always takes both.

​
Where each share lives

Neither party ever sees the other’s share. Neither party ever holds the full key.

​
How a wallet is created

Creating a wallet produces two shares at once. You keep one, the wallet the SDK returns; WalletSuite keeps the other; and the full key is never put together on any machine at any point. There is no seed phrase to write down or lose. The SDK returns the wallet as an opaque blob. It does not store it for you. You save it and pass it back whenever you sign. A single wallet works across every supported chain, so you create once and use it everywhere. See One wallet, every chain.
Wallets are 2-of-2 by default, so the wallet you hold is one of the two pieces needed to sign. Store it safely, the way you would any signing material. See Recovery.

​
How a transaction gets signed

You call a sign method with the wallet and the transaction details, both shares contribute, and you get back a normal on-chain signature ready to broadcast.
1

Call a sign method

Pass the wallet and the transaction fields to the SDK. The wallet never leaves your process as plaintext.
2

Both shares contribute

Your share and the WalletSuite share each do their part. Neither share is ever sent to the other side, and the full key is never assembled.
3

Broadcast the result

You get an ordinary on-chain signature, indistinguishable from a regular wallet. There is no special contract and no multisig wallet. The SDK signs and you choose how to broadcast, either with your own RPC or through the WalletSuite API. See Signing.
The full key is never reconstructed to sign. A signature from one transaction can never be reused to authorize another.

​
Threat model

Because it always takes both shares, no single point of failure can move funds. Here is how the design holds up in the cases people ask about most. For WalletSuite’s organization-wide security posture and audits, see Security overview.

​
What WalletSuite never does

  • Hold the full private key. It is never assembled on any machine.
  • Sign on its own. It always needs your share.
  • Read back the wallet. The SDK hands it to you once and never stores it.
  • Broadcast for you implicitly. The SDK signs, and you choose how to broadcast.

​
Next steps

Shares & thresholds

Store the wallet, run the 2-of-2 default, and see what’s on the roadmap.

Recovery

Back up the wallet durably, and see the managed recovery option.