Skip to main content
BitGo has been a CoinCover partner for a long time, and we support backup and recovery for the BitGo self-custody wallet. How you integrate depends on two things: how the wallet was created, and which backup mechanism suits that wallet. There are two ways to create a self-custody wallet — through the BitGo API, or through the BitGo web UI (console) — and each offers two backup approaches.
Selecting CoinCover in BitGo — or completing any of the backup flows below — does not on its own mean your wallets are protected. Backup only takes effect once you have a commercial agreement with CoinCover covering them. If you don’t have one in place yet, contact us before relying on any backup.

At a glance

Backup

Wallets created via the BitGo API

When the wallet is created programmatically through the BitGo API, you integrate using the CoinCover API. There are two approaches depending on the wallet type.

Multi-sig — CoinCover as a backup key

For multi-sig wallets, CoinCover acts as the backup key in your BitGo wallet. You assign a signer key via the CoinCover API (POST /v1/keys with key_type: "secp256k1", or "ed25519" for chains that use it); CoinCover generates the key pair inside our hardware-isolated key vault and returns the compressed public key. The private key is only ever handled in plaintext inside that vault; at rest it’s held encrypted, so neither you nor CoinCover staff can read it. BitGo — like most multi-sig platforms — expects a BIP32 extended public key (xpub) for each key in the wallet. An xpub is (compressed public key + 32-byte chain code) plus BIP32 metadata, and the enclave returns the compressed public key but not a chain code, so there’s no native xpub. You supply the chain code, assemble the xpub yourself, and store the chain code back with CoinCover so it’s available at recovery. You then register the assembled xpub as the backup key in BitGo’s wallet-creation key ceremony.
The worked example is the secp256k1 / BIP32 case. ed25519 keys (used by chains such as Solana) are also supported, but they follow their chain’s own hierarchical derivation scheme rather than BIP32 — the chain-code and xpub assembly steps don’t apply. The assign, store, and recovery shape is otherwise the same.

Add a backup key

The full worked flow — assigning the signer key, generating the chain code, assembling the xpub, and registering it in the key ceremony — lives on the Add a backup key page.

MPC wallets — encrypt and store a backup key

For MPC wallets, CoinCover can’t take part in the key ceremony. Instead, the customer generates their own backup key and stores it with CoinCover as encrypted material:
1

Generate the backup key

Create the backup key on your side, following BitGo’s process for the wallet.
2

Pull an RSA-4096 public key from CoinCover

Assign an rsa4096 key via the CoinCover API to get an encryption public key.
3

Encrypt the backup key

Encrypt the backup key with the RSA public key (RSA-OAEP, SHA-256), client-side. Your plaintext key never reaches CoinCover.
4

Send the encrypted package to CoinCover

Store the ciphertext with CoinCover, which holds it securely until recovery.

Back up key material

The encrypt-and-store API flow — assigning the RSA key, encrypting client-side, and storing the ciphertext — is documented in full on the Back up key material page.

Wallets created via the BitGo UI (console)

When the wallet is created through the BitGo web console, there are two backup approaches.

CoinCover selected as the backup key provider

For a set of supported multi-sig assets, BitGo lets you select CoinCover as the backup key provider during wallet creation. Behind the scenes, CoinCover acts as the backup key: it provides the public key used in BitGo’s wallet-creation key ceremony and holds the corresponding private key encrypted at rest. As part of onboarding, there’s a three-step activation:
1

Select CoinCover at wallet creation

Select CoinCover as the backup key holder when you create the wallet in BitGo. This applies to every wallet you want protected — CoinCover only holds a backup key for wallets where it has been designated at the point of creation.
2

Set up a BitGo access token

Create a BitGo access token that gives read-only access to the BitGo wallets CoinCover protects. CoinCover uses it to reconcile your wallets at backup time and confirm the correct ones are backed up. Follow BitGo’s instructions to generate the token.
3

Send the token to CoinCover, encrypted

Send the access token to support@coincover.com, encrypted with the GPG key supplied in your welcome email so it’s protected in transit. CoinCover support then validates with you which wallets we hold the backup key for.
This option is available for the multi-sig assets that BitGo supports with CoinCover as a backup key provider.

Self-generated KeyCard, backed up via the CoinCover CLI

For assets not natively supported — where CoinCover can’t be selected as the backup key provider — you generate the backup key yourself. BitGo issues a KeyCard PDF containing the key material, which you then back up with CoinCover:
1

Get a CoinCover API key

CoinCover issues you an API key for use with the CLI as part of onboarding.
2

Back up the KeyCard with the CLI

Use the CoinCover Key Vault CLI to back up the KeyCard PDF. Because the PDF is larger than the small-file limit, it uses the envelope encryption pathway — the file is encrypted on your machine and only ciphertext is uploaded.
3

CoinCover stores it under governance

CoinCover stores the encrypted package securely, with the access controls and governance managed in CoinCover Control.

CLI integration guide

Installing the CLI and running the envelope-encryption backup flow is covered on the CLI integration guide.
However you back up — CoinCover selected as the backup key, the API flows, or self-generated KeyCards via the CLI — and even across a mix of them, all your backups show up together centrally in CoinCover Control, giving you a single view of what’s protected.

Recovery

The recovery process varies slightly based on the type of backup you have completed. The most common pathway is, CoinCover releasing the material it has been holding, and you complete the recovery using BitGo’s recovery tooling.
1

Request recovery through CoinCover Control

Raise a recovery request in CoinCover Control. Release is gated by identity verification and your approval policy — the material is only released once those conditions are satisfied. As part of the request you supply a public GPG key, which CoinCover uses to encrypt the recovery package in transit.
2

CoinCover releases the held material

Depending on the backup pathway, CoinCover returns the backup private key (and, for the multi-sig key-ceremony case, the stored chain code), or the encrypted backup package for you to decrypt locally. The release is encrypted to the GPG public key you supplied, so you first decrypt it with your GPG private key before using the material.
3

Sign with BitGo's recovery tooling

Use the released material with BitGo’s recovery tooling to sign a transaction that moves the assets to a new wallet you control.
The exact recovery steps differ slightly by pathway — a key-ceremony backup key is reconstructed from the released backup private key plus the stored chain code, while a CLI or encrypt-and-store backup is decrypted locally from the released package.

What’s next

Add a backup key

The multi-sig key-ceremony backup flow.

Back up key material

The RSA encrypt-and-store flow for MPC wallets.

CLI integration guide

The CLI backup flow for self-generated KeyCards.

Partners overview

All CoinCover partner integrations.