What it does
Holds part of the recovery picture
Your customer encrypts the recovery material your architecture defines — typically a recovery-key shard — on-device, then sends only the ciphertext to us.
Verifies identity at recovery
When a customer needs to recover, they go through identity verification first. We only release the backup once the check is approved.
Encrypts in transit and at rest
Backups are RSA-OAEP encrypted on the customer’s device. Recovered material comes back GPG-encrypted to a key you control.
Notifies you in real time
Webhook events keep your backend in sync with verification state. No polling, no missed transitions.
Who it’s for
You’ll typically integrate Recover for Retail if you’re building:- A consumer wallet app (mobile or web) where customers manage their own keys
- A non-custodial product that needs a credible recovery story to compete with custodial alternatives
- A fintech onboarding flow that wants to add wallet protection as a value-add
How the integration looks
The integration sits across your backend and your wallet UI. Your customer sees an identity check at the right moments — the rest stays out of their way.A backup is created of the customer's wallet
The wallet seed phrase/private key is encrypted with a recovery key, which is then split into two shards. Shard 1 and a hash of Shard 2 are encrypted with a CoinCover public key and stored with CoinCover. Shard 2, a hash of Shard 1, and the encrypted seed phrase are stored with the wallet provider.
Biometric verification is complete
The customer will complete a biometric verification check that is link to their backup package stored with CoinCover.
Recovery triggered
When the customer needs to recover — typically months later, on a new device — they kick off a biometric verification check where we will validate that this is the same person who initially backed up.
We release our part
Once the verification is approved, we return the decrypted backup package, re-encrypted with a GPG key.
Wallet provider releases their part
Once the CoinCover shard has been recieved on the customer’s device the wallet provider will request the customer to verify the recovery is legitimate which will then trigger the release of shard 2, hash of shard 1 and the encrypted seedphrase/private key to the customer’s app.
What we hold depends on your architecture
CoinCover provides a vault primitive — we hold an encrypted blob you send us, and release it back to your customer on a successful identity verification. What that blob represents is your choice, and it depends on how your wallet infrastructure is designed. For wallet providers integrating Recover for Retail, the dominant pattern for EOA wallets is split-key recovery:- The recovery key that encrypts the customer’s seed phrase is split between you and us.
- We hold one shard, encrypted with our public key and decryptable only inside our enclave. You hold the other shard alongside the encrypted seed phrase in your own infrastructure.
- At recovery, the customer’s device combines both shards to reconstruct the recovery key, then decrypts the seed phrase locally. Plaintext exists only on the customer’s device.
- Neither side alone can reconstruct the seed phrase. Compromise of our infrastructure doesn’t compromise customer funds.
What’s next
Read the integration guide
The full backup and recovery flow, end to end.
API reference
Every endpoint, request, and response.
UI components
Embedding the Identity SDK in your wallet UI.
Testing & sandbox
Simulating verification outcomes without real customers.