> For the complete documentation index, see [llms.txt](https://shinkalabs.gitbook.io/hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shinkalabs.gitbook.io/hub/andromeda/concepts/dwallets.md).

# dWallets & 2PC-MPC

A **dWallet** is a wallet whose signing key is never assembled in one place. Instead of a single private key sitting on a device or a server, the key is produced and used through a two-party computation: the Ika network holds one share, the user side holds the other, and a signature is the output of a protocol both run together. There is no seed phrase that, by itself, controls the wallet.

This matters for three reasons:

* **No single point of compromise.** Stealing one share does not let an attacker sign.
* **No custody.** Andromeda never holds a complete key. The `prepare -> submit` pattern (see [Custody-free model](/hub/andromeda/concepts/custody-free.md)) keeps the user share on the user side.
* **Cross-chain by construction.** A dWallet is identified by a public key on a given curve. The same machinery signs for any chain that uses that curve.

## The signing lifecycle

A dWallet goes through a few stages, each exposed as a REST call. See [The signing pipeline](/hub/andromeda/guides/signing-pipeline.md) for the full walkthrough.

* **DKG (Distributed Key Generation).** Run once to create the dWallet. Produces the dWallet's public key.
* **Presign.** Produces presignatures, the expensive precomputation that makes the actual signing fast.
* **Sign.** Consumes a presignature plus a message hash and returns a raw signature.
* **Future-Sign.** Pre-authorises a signature that fires later when a condition is met. See [Future-Sign triggers](/hub/andromeda/guides/future-sign.md).
* **Imported Key.** Bring an existing key under dWallet management.
* **Re-Encrypt Share / Make Share Public.** Manage who holds the user-side share.

## Curves and chains

| Curve     | Covers                                                     |
| --------- | ---------------------------------------------------------- |
| Ed25519   | Solana, NEAR, Aptos, Cosmos (ed25519), Substrate (ed25519) |
| SECP256K1 | EVM chains, Bitcoin, Cosmos (secp256k1), Substrate (ECDSA) |
| SECP256R1 | NIST P-256, WebAuthn / passkeys                            |
| Ristretto | Substrate / Polkadot (sr25519 family)                      |

See [Chains & curves](/hub/andromeda/reference/chains-curves.md) for the full matrix.

## The chain is the source of truth

A dWallet's authoritative state lives on Solana, in the Ika program. Andromeda keeps a cache for speed and UX, but the cache is never treated as canonical. If the cache is empty during a signing flow, Andromeda recovers the dWallet state from on-chain rather than regenerating anything.

## Authority and policies

By default a dWallet is controlled by its owner. You can hand its **signing authority** to one of the [on-chain policy programs](/hub/andromeda/on-chain-programs/overview.md) so that every signature must satisfy a rule (an allowlist, a rate limit, a quorum, a confidential check). Once a policy holds the authority, the Andromeda API cannot bypass it. See [On-chain policies](/hub/andromeda/concepts/policies.md).