POST /v3/ecdsa/export
Returns the cloud node's keyshare, encrypted to a public key the client supplies. The client decrypts it and combines it with its own share to reconstruct the full private key.
Used in flow: moving a wallet out of MPC — exporting to an external wallet, or offboarding a user
Authentication: JWT (Access Token) with export:keyshare + ownership of the wallet named by key_id
This page documents the ECDSA path. The EdDSA and Taproot paths take the same request and return the same response — see Other schemes.
Request
Authorization: Bearer <access_token>
Content-Type: application/json
{
"key_id": "3f9a...c21b",
"client_enc_pubkey": "a17d...09f4"
}
| Field | Type | Required | Description |
|---|---|---|---|
key_id | string | Yes | Hex-encoded key ID of the wallet to export, 64 characters. Must belong to the authenticated user. |
client_enc_pubkey | string | Yes | Hex-encoded x25519 public key, 64 characters. The node encrypts its share to this key. |
Not base64. key_id is the same hex string the SDK exposes as keyIdHex, and client_enc_pubkey is the publicKeyHex of a freshly generated encryption keypair.
Generate a new encryption keypair for every export request. It is the only thing standing between the encrypted share and anyone who observes the response.
Response
{
"key_id": "3f9a...c21b",
"server_public_key": "5c02...7ae8",
"enc_server_share": "91bf...d430"
}
| Field | Type | Description |
|---|---|---|
key_id | string | Hex, echoed from the request |
server_public_key | string | Hex-encoded x25519 public key, 64 characters. The node's ephemeral public key, needed to decrypt the share. |
enc_server_share | string | Hex-encoded ciphertext: a 24-byte nonce followed by the NaCl crypto_box sealing (X25519 key agreement) of the node's share. |
The node generates a fresh keypair per request, so server_public_key differs every time.
Decrypting enc_server_share and combining it with the client share reconstructs the private key — see Export Key for the per-platform SDK calls. Going through auth-svc changes nothing about that step: only the base URL and the Authorization header differ from calling the node directly.
auth-svc cannot read the share it forwards: the node seals it to client_enc_pubkey, and only the client holds the matching secret.
Other schemes
Every path takes the request and returns the response documented above. Only the URL changes.
| Scheme | Endpoint |
|---|---|
| ECDSA | POST /v3/ecdsa/export |
| EdDSA | POST /v3/eddsa/export |
| Taproot | POST /v3/taproot/export |