Who really holds the key?

For years that was the first question an institution put to a custody provider. It is now settled: across the six platforms we examined, not one describes a model in which the vendor can sign on its own.

Fireblocks puts it plainly: “at no point does Fireblocks have enough key shares to unilaterally sign a transaction.” The other five describe the same split, The Vault included.

So the question moves one step. We compared The Vault with Fireblocks, Utila, Dfns, Copper and Taurus. What separates them is not who holds the key but who else can hold a copy of it, how much of the platform you can run yourself, who decides when a person must sign, and one more thing that does not fit in a table.

The documented picture

✓ means the platform documents this in full, ◐ that it is partial or limited; where we could not confirm something from public sources, that does not mean the capability is absent. One more difference does not fit a table: whether the platform looks at what it is moving. The rest of this piece takes the four in turn.

Where the real differences are

Who can hold a copy of your share

A share on a device is only as private as its backups, and this is where the group splits. Fireblocks documents keeping an encrypted copy of the phone's share on its own servers, so a lost or damaged phone can be reinitialised; the passphrase the user chose is what keeps that copy unreadable, and in the embedded line the share is encrypted under a key the application or the user generates and then sent to Fireblocks for safekeeping, with the user storing the key themselves. Copper names the practice in its own writing and says it keeps no record of the shards belonging to the client and the trusted third party. Utila puts the recovery package in the client's hands: an encrypted vault backup that the customer's own RSA key opens, and recovery proceeds without Utila. It also documents the other direction: for its server co-signer the signing keys are downloaded onto a machine the client runs, which keeps them inside the customer's perimeter but does copy them there, into a folder that may sit in the client's own cloud storage. Taurus treats restoration as a ceremony with separated roles, and the encrypted recovery package sits with the client or with a provider the client picks. Dfns is a different shape again: in hosted deployments it holds the shares itself, in hardware-attested enclaves.

On The Vault a device's share stays in hardware-backed storage on the phone, and a signing operation refuses to run if that storage is unavailable. Recovery is exported as encrypted QR codes that the operator keeps and opens with a phrase only they hold; the platform keeps nothing it could hand over, and all our servers know is how many keys a device should have, so a partial restore cannot be passed off as a complete one. Four of the six platforms leave that material with the customer in one form or another, so the useful question to put to any provider is not whether it has a mobile signer, but whether a copy of your share exists anywhere you do not control, and what single secret protects it.

What you can run in-house

Almost every vendor now runs something on the client's side, and almost always it is one component. Fireblocks lets clients host co-signer software in an enclave, on their own machine or VM, in any major cloud. Copper publishes a signing service the client deploys in containers. Utila runs a co-signer in the client's own environment. Dfns documents a self-hosted signing stack, where the client manages all key shares in its own data centres.

Those are real, and they are not the same thing as holding the platform. In each case the policy engine, the approvals and the transaction orchestration stay with the vendor. Alongside SaaS, The Vault can run the whole platform in the institution's own infrastructure, and of the other five only Taurus documents the same.

That matters beyond where the servers sit. When the entire platform runs in-house, the institution can plan its own security and audit work around it. It does not follow automatically: source access, external dependencies, licence terms and a tested recovery procedure are contract questions, and they should be settled in the contract rather than assumed from a deployment diagram.

Whether you set the human requirement

Every platform here can require a person to approve a transaction. The difference is who decides how strict that requirement is, and whether it is cryptographic or procedural.

On Utila the answer is fixed by architecture: two parties, the customer's share bound to a device, and a transfer created in the console must be signed on that device. Fireblocks documents two-of-two for its embedded wallets and nowhere describes the customer choosing a scheme; the mobile app is the manual path, and the API Co-Signer signs automatically, with nobody tapping it. Copper's vault is two-of-three, and the client picks each vault's temperature: hot vaults sign automatically, cold ones need both the client and Copper. Taurus offers several approval methods including a mobile app, with a web and desktop key container as the documented default, but those are user approval keys rather than MPC signing shares, and service accounts sign through an API key.

Two platforms let the client set the rule rather than pick from presets. Dfns lets customers choose the threshold scheme in its hybrid and on-premise models, and says any configuration can be implemented; in its fully managed model the question does not arise. The Vault sets the threshold and the participants when the master key is generated. Put fewer shares on servers than the threshold requires and no combination of servers can sign, so the person initiating a transaction signs on their own device. Create the key server-only and it runs unattended. The same institution can hold its treasury on keys that always require a person and still run payouts from server-only keys.

That is a rule an institution can check rather than take on trust: the number of shares held on servers sits below the threshold, and that arithmetic is visible when the key is created. For a treasury the price of it is small: few transactions, each large enough to be worth signing by hand.

The fourth difference: whether the platform knows what it is moving

The first three differences are about who can sign and who holds the material. This one is about what gets signed. Tether and Circle keep on-chain lists of addresses they have frozen. Send a stablecoin to one of them and, depending on the token, the transfer either fails or the funds sit at the destination out of reach.

The Vault checks for that before it lets a transfer through. When the transfer is created, the recipient is checked against the issuer's own list (USDT and USDC on EVM chains, USDT on TRON), and if the check cannot run, because the node does not answer or the call times out, the transfer is rejected rather than passed through.

Two limits are worth naming. Tokens outside that set are not checked. And an address can be frozen between broadcast and inclusion, which is a race no provider can remove.

The Vault does this as a behaviour of the platform itself, and we found no comparable control documented by the other five. A policy engine or a callback hook can be made to do the same job, but that is something the customer builds and then maintains. Here it is simply how a stablecoin transfer is handled.

Questions to ask any provider, including us

Public documentation will not settle all of these. Ask for the artefacts.

1. Which parts of the platform can we run in our own infrastructure, and which stay with you? Give us the component list, the external dependencies and the licence terms.
2. If the relationship ends tomorrow, how do we keep signing and how do we migrate? Has that procedure been tested?
3. Can any combination of your servers produce a signature without a person taking part? If so, can we change that, and is it set per key, per workspace or per deployment?
4. Is approval of a policy change switched on by default, and can the person who requests a change approve it themselves?
5. Who holds each key share, and can the threshold change later, or only when the key is created?
6. What exactly happens when a stablecoin transfer is created or signed and the destination has been frozen by the issuer? Which chains and contracts are covered, and what happens when the check itself fails?
7. For any trusted execution environment you claim: show the deployment manifest, how quotes are verified, which measurements are accepted, and a test that rejects a bad one.
8. Does any signing material get downloaded onto the components we run, and does a copy of a device’s key share exist anywhere outside our own perimeter? If it does, who can decrypt it, and what single secret stands in the way?

Question four is a fair one to put to us as well. Question seven is the one every vendor in this market, us included, should expect to be asked and should be able to answer with artefacts rather than adjectives.

What this comparison leaves out

We looked at deployment boundary, key control, custody of key material and asset-level controls. Chain coverage, monitoring providers, certifications and pricing are outside this comparison, and each platform here is known for things we did not weigh. Depending on how you operate, any of them may matter more than the rows above.

Talk to us

If you would like to go through these questions with The Vault, our team can show you how the key model, the deployment boundary and the recovery path would map onto your current approval process.

Sources

Information about other vendors comes from their own websites and developer documentation, read in October 2026. “Not published” means we could not confirm a capability from public sources; the vendor may offer it privately or may have added it since. We will update this page as documentation changes, and vendors are welcome to send us corrections.

• Fireblocks: principles; co-signer architecture; approval quorums; embedded wallet keys; backup and recovery
• Utila: security; sign a transaction; co-signer; admin quorum; CLI state
• Dfns: deployment models; security model; FAQ; product features
• Copper: vaults; what is secure custody; Unlimited Online; transfer approval
• Taurus: platform capabilities; Protect; signing for approval; wallet recovery with Coincover
• Stablecoin issuers: Circle EVM token contract; Tether supported protocols