> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletsuite.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture & Security

> How your keys stay safe. The 2-of-2 share model, how wallets are created and transactions are signed, and the threat model behind self-custodial MPC wallets.

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](/mpc/key-shares).
* **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

|                        | You                                                                      | WalletSuite                                 |
| ---------------------- | ------------------------------------------------------------------------ | ------------------------------------------- |
| **Holds**              | The wallet (one share of the key)                                        | The other share of the key                  |
| **Lives**              | Your storage (database, KMS or HSM, device, passkey-wrapped envelope)    | Server-side, fully managed by WalletSuite   |
| **Can see**            | Its own share, plus the public address                                   | Its own share, plus the public address      |
| **Can do alone**       | Derive addresses locally with no network call. Nothing that moves funds. | Nothing. It cannot sign without your share. |
| **Needs the other to** | Sign a transaction                                                       | Sign a transaction                          |

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](/mpc/curves).

<Note>
  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](/mpc/recovery).
</Note>

## 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.

<Steps>
  <Step title="Call a sign method">
    Pass the wallet and the transaction fields to the SDK. The wallet never leaves your process as plaintext.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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](/mpc/signing).
  </Step>
</Steps>

<Note>
  The full key is never reconstructed to sign. A signature from one transaction can never be reused to authorize another.
</Note>

## 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.

| Scenario                          | What happens                                        | Why funds stay safe                                                                                                                                                             |
| --------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Your share stolen**             | The attacker has one share of two.                  | One share on its own is inert. It cannot sign without WalletSuite, and WalletSuite only signs for an authenticated request from your account. There is no seed phrase to phish. |
| **WalletSuite share compromised** | The attacker reaches the WalletSuite share.         | It cannot sign without your share. It never holds the full key, and one share reveals nothing about the other.                                                                  |
| **One party offline**             | Either side is unreachable.                         | No signature completes. Signing needs both sides, so an offline party means no transaction is produced.                                                                         |
| **Network interception**          | An attacker intercepts traffic between the parties. | Shares never travel the wire, and what does travel reveals nothing about either share or the full key. Transport is HTTPS.                                                      |

For WalletSuite's organization-wide security posture and audits, see [Security overview](/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

<CardGroup cols={2}>
  <Card title="Shares & thresholds" icon="key" href="/mpc/key-shares">
    Store the wallet, run the 2-of-2 default, and see what's on the roadmap.
  </Card>

  <Card title="Recovery" icon="life-ring" href="/mpc/recovery">
    Back up the wallet durably, and see the managed recovery option.
  </Card>
</CardGroup>