Security & Trust

Every key in your vault belongs to you or to someone you chose. We hold none, and never have — no vault in production has ever contained a key we controlled. Two of the three are required to move Bitcoin, so we cannot produce a signature: not through a bug in our code, not if our servers were taken over, not under a court order.

That is a claim about spending, and only about spending. A compromised Keystody could still mislead you — most importantly by showing you the wrong address to pay into. Section 3 describes that attack honestly and section 5 gives you the check that defeats it.

What we do hold is the public information needed to watch your vault and prepare transactions: extended public keys, output descriptors, derivation paths and addresses. That is not spending power, but it is not harmless either — see section 4.

And it is testable rather than promised — by you, not only by us. Export your vault, rebuild it in Sparrow or Bitcoin Core with Keystody closed, and move a small amount out of it while nothing is wrong. Section 6 explains how, and what we verify on our side on every change.

Private keys are created on your hardware wallets and never leave them. Keystody prepares unsigned transactions and hands them to your devices; the signatures come back, and we broadcast the result. At no point does signing material cross into our systems.

This is the question worth asking of any coordination platform, and most do not answer it. Here is ours.

The addresses you see are computed on our servers. A compromised Keystody could not spend from your vault — that needs two of your keys — but it could show you the wrong receive address, or a transaction whose change output goes somewhere else. Nothing on the screen would look unusual.

Your hardware wallet is the check. It holds one of the three keys and re-computes the address from your vault’s full key set — the two-of-three script, not just its own key — on a screen no website can reach. That check is only as good as the key set, so confirm it once. On Ledger the device asks you to approve the vault as a named policy and shows all three keys; on Trezor and air-gapped devices you compare the three fingerprints against your Recovery Document yourself. After that, an address matching on both screens is an address your keys control. Before signing, the device should show exactly the payments you intended and nothing else — one unexpected recipient is the attack.

The device settles what an address is. It does not settle whether we are showing you your whole vault — for that, keep your descriptor and check your balance in third-party software now and then (section 6).

How to verify on your device →

To show balances and build transactions we store your extended public keys (xpubs), output descriptors, derivation paths, master fingerprints and addresses.

None of this can spend. But together these keys derive every address your vault will ever use — past and future — so anyone holding them can watch your balance and your whole transaction history, permanently: an exposed extended public key cannot be revoked or rotated, only outrun by moving to a new vault. We treat it as sensitive financial data, and you should too.

Encrypted at rest. These fields are encrypted with AWS KMS before they reach the database, with automatic annual key rotation. A stolen database snapshot or backup does not expose them.

Readable by the running application. We want to be precise rather than flattering here: the application decrypts this data in normal operation, because it needs the public wallet metadata to derive addresses and build transactions. So a compromise of the running system is different from a compromise of the database, and would expose wallet metadata. Access to production is restricted and logged.

The current application is configured not to write extended public keys, descriptors, PSBTs or recovery exports to application logs. We state it that way deliberately: it describes how the system is configured today, which we can verify, rather than making a claim about everything the software has ever done.

Bitcoin addresses do appear in operational logs — they are public data, and our sync and support paths need them. Those logs are deleted after 90 days.

We keep three kinds of record, in three different places. Operational logs, the only ones containing addresses, go at 90 days. Authentication events — sign-ins and failed sign-ins — are held separately and also go at 90, because answering “who signed in, from where” is the question a security incident actually turns on. Administrative actions, such as a permission change or a member being removed, live in your account’s audit history for as long as the account does, because that is a record you can inspect.

An address set is linkable even though each address is public, so the length of that window is a real trade-off and we would rather state it than round it down. Ninety days is what an incident reported well after the fact needs: a log that has already expired makes the honest answer to a security question “we cannot tell”.

We do not hand your addresses to a chain-data provider. Watch-only wallets normally query public Electrum servers, which hands a stranger every address in your vault and the IP asking about them. Keystody runs its own Bitcoin node, and on mainnet that is enforced in code rather than configuration — there is no environment variable that can quietly point production at a public server. See section 7.

The limit of that: it covers the queries we make on your behalf. Your addresses are still visible on the public blockchain to anyone who has them, to whoever you transact with, to any block explorer you look them up in yourself, and to anyone holding a copy of your descriptor. Testnet vaults are served by public Electrum servers, not by our node — the protection described here is a mainnet property.

You do not have to take section 3 on faith. Address derivation is deterministic, so anyone can confirm we compute addresses correctly.

This is a throwaway testnet vault, built from test seeds and holding nothing. Its descriptor:

wsh(sortedmulti(2,[075f05fd/48h/1h/0h/2h]tpubDEP6pAW1JoGkLa6Vuoxo4vjVtvaPxXEHcCAnqYAATkgWFaSjrGPFrdFMt2LGNB7zDFwoPTE4UttdGknkvz2R2eTs4HykDhrrhpmz8u9y2HG/0/*,[31353d0b/48h/1h/0h/2h]tpubDFChRDufGVcRBBVqz8UcXhdUXRLAxSSLFpwygPLF35VtFAm2ovgzuT7W9Mrc8T2GVJasVssViefTovS2fXRxunRvyAqTVDDrJHWVUTrfiag/0/*,[f41eddcc/48h/1h/0h/2h]tpubDFi8N9yZYVxtrYNfdLUkiuBQWbKiAGwWphPfGbJD1gNmRC4Kj7tvWzuCzwDvP1JMe6UdUYxqDX91WTifiJugwzMom9AFwb7XYgbHcExbzAy/0/*))#8cnteyj5

Copy it as a single line — a descriptor with line breaks in it will not validate. Then run it through Bitcoin Core. No blockchain sync is required; deriving addresses is pure computation:

bitcoind -testnet -maxconnections=0 -daemon

bitcoin-cli -testnet deriveaddresses "<descriptor>" "[0,2]"

The first three addresses are:

tb1qengd4jssrewfkn4wzyd6u40rq0daufcm06df4dda8aph9alj38cqkx2xgw
tb1qztzvvgtvlw25tarmywh2yqzpctqwsykjr3r8xsral33zsvksrudswrxvza
tb1qrr7peagjqrtk3f70s3mrr29szrdwttzdvsnjqzn7t7g0td6klqzssls7ar

Keystody derives exactly those, and every build we ship re-runs that comparison. If our derivation ever diverged from the reference implementation, the build would fail before it reached you.

This proves our maths, not our honesty at the moment you look at a screen. That is what your hardware wallet is for — section 3.

Your vault is a standard Bitcoin multisig described by an output descriptor — a public specification, not a Keystody format. Any descriptor-aware wallet can reconstruct it from the file you export, find your funds, and spend them with two of your keys. We are not part of that process.

You do not have to take our word for that, and you should not. Export your vault, rebuild it in Sparrow or Bitcoin Core with Keystody closed, and check the first receive address matches character for character. Then, while nothing is wrong, move a small amount out of the rebuilt wallet. That last step is the one that counts: reconstructing a vault shows the descriptor is well-formed, but only signing shows the key set can actually spend. Both guides are linked below.

Do that once and the answer is yours rather than ours — for your vault, on your hardware, in the version of the software you actually run. And the export you keep is a file: nothing we ship afterwards reaches back and changes it.

What we check on every change. Our address derivation is compared against reference vectors produced by Bitcoin Core v31.1.0, and the build fails if a single address diverges. Bitcoin Core is the reference implementation, so agreeing with it is the standard worth holding ourselves to — and this runs on every change rather than on a date.

What we have tested by hand. A mainnet recovery was completed on 11 July 2026: a vault exported, rebuilt in third-party software with Keystody closed, and a real transaction broadcast with real Bitcoin. The software versions used were not recorded, so read it as evidence the procedure worked on that date rather than as proof of compatibility with the release you are running. A versioned re-test is pending. Sparrow and Bitcoin Core are the two we have tested ourselves; other descriptor-aware wallets should read the format because it is standard, but we will not claim compatibility we have not verified.

The full recovery guide →
How to rehearse it while nothing is wrong →

• Hosted on AWS in Frankfurt (eu-central-1). Database, encryption keys and application all run in the EU.
• Encrypted in transit (TLS) and at rest. Field-level encryption with AWS KMS for wallet metadata, with annual key rotation.
• Daily automated database backups, encrypted, retained in the EU.
• Certificate issuance for keystody.com is restricted by CAA records, which instruct certificate authorities not to issue for our domain unless we named them. CAA binds authorities that follow the rules, checked at the moment of issuance — it is not a technical barrier, and it would not stop an authority that ignored it or one that had itself been compromised.
• Authentication through AWS Cognito, with two-factor authentication required — not offered as an option. Until you enrol an authenticator, the API refuses every request for your account.
• Chain data comes from our own Bitcoin node and Electrum server, never a public one. On mainnet this is enforced in code, not configuration. The only outbound third-party call is a block-height cross-check against public explorers to detect an eclipse attack on our own node — it sends a block number and nothing else.
• The marketing site loads no analytics and no third-party scripts at all.

We use a small number of third parties. There is no analytics provider on this list, and no Bitcoin data provider either — chain data comes from our own node, which is why nobody outside this list ever sees a vault address.

Last reviewed 19 August 2026. We update this list when it changes. Details of what we collect and why are in the Privacy Policy.

If Keystody ceases operating, we will give as much notice as circumstances allow, keep vault exports available throughout that period, and destroy wallet metadata rather than transfer or sell it.

Your ability to recover does not depend on any of that. The descriptor you already hold works without us — which is why we ask you to keep it somewhere safe and offline from the day you set up.

No — and the more useful question is what you can verify anyway. Open source is not the same as audited, and closed source is not the same as unverifiable. What matters is whether you can check the things that could cost you money, and you can: the addresses you are given (section 3), our derivation of them (section 5), and your ability to recover without us (section 6).

If we open any part of this, it will be the recovery and verification path first, because that is the code where independent scrutiny is worth most.

Email security@keystody.com, or read the disclosure policy for scope, testing rules and what to expect. We acknowledge reports within three business days.