What your auditor can verify without trusting you in crypto

Find out why recovery is crypto’s last unverified room, and how audit is forcing it open.

Written by Tommy Jamet · Head of Product, CoinCover · May 2026

A signed claim you can’t independently check is still an assertion.

The hardest question in an audit isn’t on the checklist.

It lands after the policies are reviewed, and the architecture diagram gets the polite nod. The auditor asks the institution to prove the recovery path can’t be quietly abused, that no single hand can pull the assets back and walk. The institution points at its custody vendor. The vendor says trust us, we’ve handled it. Everyone nods. The meeting moves on.

Nothing in that exchange was verified.

That’s the moment worth naming. Not because anyone lied, but because a roomful of careful people just accepted a promise and recorded it as proof. Crypto made settlement independently verifiable at the protocol layer. The recovery and key-custody layer never did. It still runs on the operator’s word, and on the vendor’s word beneath it.

A signed claim you can’t independently check is still an assertion. A verification that bottoms out in trust me is just trust wearing a verification costume. The test that separates the two is a single question: who must cooperate with you to confirm the claim? If the answer is the vendor, it’s a promise. And the thing forcing recovery to catch up isn’t regulation. It’s the auditor in the room.

Crypto solved this once, then stopped at the vault door

The founding move was removing trust from settlement. A transaction clears, and anyone, with no permission and no relationship to the parties, can read the chain and confirm it happened. You don’t trust the exchange. You check.

That principle won settlement. Then it stopped at the vault door. The layer that protects against catastrophic loss, key backup and recovery still asks customers and auditors to trust the operator, and to trust the operator’s vendor underneath.

In February 2025, Bybit lost $1.5 billion ^{(1) (2)}. It left through the signing layer, not the chain.

The chain did its job. The human-and-vendor layer above it is where the money left. That’s the gap. And the thing closing it isn’t a new rule arriving first; it’s the auditor treating verifiable recovery as table stakes before the regulation has finished spelling it out.

Two kinds of assurance, not close to equal

Start with the distinction the whole question turns on.

Assertable assurance holds because someone promises and behaves. I tell you it’s true. Maybe I show you a document. Maybe an auditor I hired confirms that I told them so. Every link in the chain terminates at me, and you believe it because you’ve decided to believe me.

Verifiable assurance holds because of math or structure, independent of how anyone behaves. You check it yourself, against something I can’t quietly edit, without needing my cooperation at the moment you check. No link terminates at me. You believe it because you saw it.

There is a trap between the two, and some custody setups still rely on vendor assertions, not independent verification: verification that still ends in trusting the vendor. A dashboard that shows green because the vendor’s own system rendered green. An attestation signed by the vendor, about the vendor. A SOC 2 report the vendor commissioned. Pull the thread on any of it and you land back in the same place. Real verification does not end in anyone’s word; the vendor’s included.

Four questions for your next vendor call

These work on anyone selling you custody.

Key provenance.

Can a third-party check where your keys came from and how they’re bound to you, or can the vendor only assert it?

The recovery record.

When a recovery runs, is there a record that cannot be edited after the fact, or one the vendor can reformat before you see it?  

Single-party recovery.

Can any one party, inside the vendor or inside your own team, complete a recovery alone? A recovery path one hand can run is a custody risk wearing a recovery label. The bar to look for is multi-party by design: independent material and a governed approval step, so no single actor acts unchecked. Ask too how much of that is enforced by structure today and how much is still policy, because the honest providers will tell you which is which, and which they are still moving across.

Cryptographic or operational.

Cryptographic protection holds whether or not people behave.

Operational protection holds until someone doesn’t.

That last question is the sorting hat. Most of what gets called a “control” in custody is operational wearing the language of the cryptographic. The questions don’t ask anyone to be more honest. They ask whether honesty is even load bearing.

The honest part most vendors skip

You can’t push trust to zero.

You can't push trust to zero, and in recovery you should not want to. Every recovery architecture has a residual trust boundary somewhere: a hardware maker, a cryptographic assumption, a physical room with a door. Push past the last of them and you reach the point where only the customer can open the lock, which is not security, it is a second way to lose the keys. Zero trust in recovery means zero recoverability. The trust-free custodian does not exist, and anyone selling one is back in costume.

So the test isn't whether the boundary exists, it's whether the provider names it. One who shows you where it sits, plainly, at the base of everything else, is handing you a risk you can see and price. One who leaves it buried and unnamed is asking you to inherit one you can't. Ask where it is. The answer, or the refusal to give one, tells you most of what you need to know.

What moving the boundary looks like

A concrete example: a public verification endpoint, where an outside party confirms a claim directly, with no login to the vendor’s dashboard and no vendor in the loop at the moment of checking. Point it at key provenance, and you get third party-checkable confirmation that a key was issued and customer-bound, without taking the vendor’s word for it.

That’s the direction this moves at Coincover. The customer-bound piece is work ahead of us, not a box already ticked, and the shape is what matters.

The fewer facts that depend on the vendor’s goodwill, the more your audit is actually worth.

The board agenda is changing

“Are we secure?” was always answerable with a confident voice and a green slide. “Is our recovery auditor-ready?” is not. It means independently verifiable, not self-attested. CoinCover Certified is the first move toward that: it turns an institution's recovery posture into structured, auditor-ready evidence on a renewal cycle, not a one-time claim. Making those facts checkable with no vendor in the loop is the verification work above, and it is still ahead of us.

Before your next audit

The edge in this market stopped being a stronger claim a decade ago, the moment settlement went verifiable. Recovery is the last room where the old game still works, and it is a harder room, because the goal is not just verifiable, it is verifiable and recoverable at once: a claim you can check, on a recovery path that no single hand can run unchecked and no single failure can lock shut. Run the four questions on your own setup before your next review. The answers will tell you which of your assurances are real, and which ones are just well-dressed.

If you want to know how long that lasts, run the four questions on your own setup before your next review.

The answers will tell you which of your assurances are real, and which ones are just well-dressed.

Sources:

1. https://www.nccgroup.com/research/in-depth-technical-analysis-of-the-bybit-hack
2. https://tradersunion.com/brokers/crypto/view/bybit/bybit-hack-2025/

DISCLAIMER: This article does not constitute audit, legal, or regulatory advice, and capabilities described may vary depending on implementation and recovery model. Tommy Jamet leads product at CoinCover. He writes field notes on key custody, recovery, and the audit reality reshaping institutional crypto.