> 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/guides/dwallets.md).

# Manage dWallets

This guide covers the lifecycle calls for a dWallet beyond creation and signing. For the concept, see [dWallets & 2PC-MPC](/hub/andromeda/concepts/dwallets.md). For exact bodies, the [OpenAPI spec](https://api.andromedainfra.pro/openapi.json) is canonical.

## Create

* **High-level (recommended, MCP tool `create_dwallet`):** `POST /v1/dwallet/create` with a passphrase — Andromeda runs the DKG server-side and stores the wallet's key wrapped under the passphrase.
* **Low-level:** `POST /v1/dwallet/dkg/prepare` then `POST /v1/dwallet/dkg/submit` — you run the MPC client side yourself.

See [Create a dWallet](/hub/andromeda/getting-started/create-dwallet.md) for both, the passphrase model, and the pre-alpha disclaimer.

## Presignatures

Signing consumes presignatures (single-use). Allocate them ahead of time.

* **Allocate (high-level, MCP tool `presign`):** `POST /v1/dwallet/presign` with `{ dwalletAddress }` — no passphrase needed.
* **Allocate (low-level):** `POST /v1/dwallet/presign/submit`.
* **Inventory:** `GET /v1/dwallet/presigns/{userPubkey}` returns the available presignatures. Keep a buffer if you sign in bursts.

## Sign

* **High-level (MCP tool `sign_message`):** `POST /v1/dwallet/sign` with the dWallet, the raw message, the scheme, the on-chain approval proof, and the passphrase.
* **Low-level:** `POST /v1/dwallet/sign/submit` — you did the MPC client side.

A dWallet must be delegated to a policy program to be signable (only a program can authorise the on-chain `MessageApproval`). See [Sign a message](/hub/andromeda/getting-started/sign.md).

## Future-Sign

Pre-authorise a signature to fire later when a condition matches.

* **Arm**: `POST /v1/dwallet/future-sign/submit`.
* **Complete**: `POST /v1/dwallet/future-sign/complete/submit` when the trigger fires.

You usually drive this through a [Future-Sign trigger](/hub/andromeda/guides/future-sign.md) rather than calling complete by hand.

## Imported keys

Bring an existing key under dWallet management instead of generating a fresh one with DKG. Use this when you are migrating a wallet that already has on-chain history. See the import endpoints in the OpenAPI spec.

## Share management

The user-side key share can be moved or published:

* **Re-encrypt the share to a new holder**: `POST /v1/dwallet/re-encrypt-share/submit`.
* **Make the share public**: `POST /v1/dwallet/make-share-public/submit`. This changes the trust model of the dWallet; only do it deliberately.

## Attach a policy

To make signing conditional on a rule, hand the dWallet's authority to a policy program. See [Deploy a policy](/hub/andromeda/guides/deploy-policy.md). Once a policy holds the authority, every signature must satisfy it, and the API cannot bypass it.

## Recovery

To make the dWallet recoverable, configure the `rules-policy` program with a primary owner and (optionally) a quorum roster. See [Configure recovery](/hub/andromeda/guides/configure-recovery.md).

## Idempotency

Every mutating call here accepts an `Idempotency-Key` header. Use it, especially for DKG and signing, so a retry does not start a second DKG or burn a second presignature. See [Idempotency keys](/hub/andromeda/guides/idempotency.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://shinkalabs.gitbook.io/hub/andromeda/guides/dwallets.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.