Threat Model

This document describes Sigvault’s security architecture in terms a reviewer can verify rather than take on faith. It names the system’s components, the adversaries it defends against, and — most importantly — the trust boundaries that determine what each component is and is not capable of doing.

The goal is not to claim Sigvault is unbreakable. It is to make Sigvault’s security properties legible: a careful reader should be able to read this document, read the open-source code it references, and reach the same conclusions we have about which attacks are mitigated and which are not.

System Overview

Sigvault has four trust domains. Each performs a specific role and is constrained by what it can or cannot see:

Component	What it holds	What it can do
Hardware wallet	Private keys (user-managed)	Sign transactions when the user physically approves on-device
Desktop application (open source)	Nothing persistent; bridges hardware to backend	Construct PSBTs, route signing flows, render transactions for user verification
Cryptographic backend service (open source)	Encrypted system-managed keys, wallet descriptors	Coordinate signing ceremonies, enforce policy, sign with system-managed keys
Business backend (closed source)	User accounts, sessions, billing, audit logs	Authenticate users, route messages, surface UI; cannot alter cryptographic outcomes

Funds are held in Bitcoin output scripts that reference public keys derived from these components. No single component above can move funds on its own unless the wallet is configured to use a system-managed key as the sole signer. That configuration is opt-in and labeled custodial throughout the documentation.

Trust Boundaries

The most important question for any custody system is: what assumption does each layer require, and what happens if that layer is fully compromised? This section answers that for each layer.

Hardware Wallet

You trust the hardware wallet to:

Generate and protect the private key inside its secure element
Display the destination address and amount accurately on its own screen
Sign only the transaction the user approves on-device

If the hardware wallet is compromised — for example, by a malicious firmware update or a physical supply-chain attack — funds protected by that single device are at risk. This is true of any wallet built on hardware security and is the reason Sigvault recommends multi-device configurations for significant value.

Desktop Application

The desktop application is open source and distributed with reproducible builds. You trust it to:

Faithfully relay transaction data between the hardware wallet and the backend
Render PSBTs accurately in the UI so you can verify them before approving on-device

A compromised desktop binary cannot, on its own, steal funds protected by a hardware wallet — the user must still approve the transaction on the device’s own screen, and the device displays the destination and amount independently. A compromised desktop binary can mislead the user about which transaction is being signed if the user does not check the hardware wallet’s screen. Always verify destination and amount on the hardware wallet itself.

Cryptographic Backend Service

The cryptographic backend service is open source and is the component that any third-party reviewer must scrutinize most carefully. It coordinates signing ceremonies and, for system-managed keys only, holds private key material under encryption.

You trust this service to:

Enforce wallet policies (multisig thresholds, taproot script paths, time locks)
Refuse to produce signatures that violate a wallet’s declared spending conditions
Hold encrypted system-managed key material such that it cannot be exported in plaintext from the running service
Produce signed audit records for every operation

A reviewer reading the open-source code can verify the invariants in Cryptographic Invariants below.

Business Backend

The business backend handles user accounts, sessions, notifications, billing, and the support dashboard. It is intentionally outside the cryptographic trust path. Even a fully compromised business backend cannot:

Produce a valid Bitcoin signature
Read system-managed key material in plaintext
Bypass a wallet’s spending conditions
Alter the cryptographic backend’s audit log without detection

It can affect availability, account access, and metadata — see Residual Risks.

Custody Models and What Each Trusts

Sigvault supports three custody models. The trust assumptions for each are different and should be understood before choosing.

Non-Custodial (User-Managed Keys Only)

All signing keys are on hardware wallets controlled by the user. Sigvault stores only public keys (xpubs).

Sigvault cannot sign for you. A complete compromise of every Sigvault component does not move your funds.
You can recover without Sigvault. The wallet descriptor plus your hardware wallet seed phrases is sufficient to spend on any compatible Bitcoin wallet software. See Recovery Without Sigvault.
This is the recommended configuration for personal cold storage and significant balances.

Collaborative (Mix of User-Managed and System-Managed)

The user holds one or more hardware wallets; Sigvault holds one or more system-managed keys, typically as a recovery or convenience signer. A 2-of-3 with two user devices and one system key is the most common pattern.

Sigvault alone cannot sign. It does not hold a quorum of keys.
The user alone can sign with their devices. Independent of Sigvault.
Together, the user and Sigvault can sign — useful for assisted recovery if one user device is lost.
This is the recommended configuration for shared or business custody where some operational assistance is desired.

Custodial (System-Managed Keys as Sole Signer)

Sigvault holds the private key material; signatures can be produced without user device interaction.

Sigvault can sign on your behalf. This is useful for hot wallets, automated workflows, and programmatic spending.
You are trusting Sigvault’s infrastructure with funds protected by this key. A compromise of the cryptographic backend service in this configuration could result in fund loss.
This is appropriate for hot wallets, small operational balances, and use cases where the convenience of automation outweighs the trust requirement.

The custody model is a property of how a wallet is configured, not of Sigvault as a whole. Different wallets in the same account can have different custody models.

Adversaries

Sigvault is designed against the following adversaries. Each is named explicitly so reviewers can challenge whether the mitigations are adequate.

External Network Attacker

An attacker on the network with no insider access. May intercept traffic, observe metadata, attempt to compromise endpoints, replay or modify in-flight messages.

Mitigations. Authenticated and encrypted transport for all client-server traffic. Signatures are produced on hardware wallets with on-device verification, so a network attacker cannot substitute destinations or amounts without the user noticing on the device screen. PSBTs are integrity-protected end-to-end.

Malicious or Compromised Sigvault Operator

An attacker with full access to Sigvault’s infrastructure — servers, databases, deployment pipelines, employees. This is the worst-case insider threat.

Mitigations. For non-custodial and collaborative wallets, the operator does not hold a quorum of keys and cannot sign. Spending policies are enforced in the open-source cryptographic service, whose code can be reviewed and whose deployed binary can be verified against published source via reproducible builds. For custodial wallets, this adversary is not mitigated — see Residual Risks.

Compromised Single Hardware Wallet

A single hardware device is compromised through firmware backdoor, supply-chain attack, or physical extraction.

Mitigations. Multi-device configurations (multisig, taproot vaults with multiple conditions) ensure that a single compromised device cannot move funds. We recommend using devices from different manufacturers in the same wallet to avoid simultaneous firmware vulnerabilities.

Coercion of an Individual Signer

An attacker physically coerces a key holder into signing.

Mitigations. Multisig thresholds requiring multiple signers in different physical locations. Time-locked recovery paths in taproot vaults so that even an attacker holding one key cannot immediately empty the wallet — recovery quorums can be alerted and intervene during the time-lock window.

Coordinated Insider + Operator

A user-side insider (one signer of a multisig) collaborates with a malicious Sigvault operator.

Mitigations. Wallet policies are designed so that no operator + insider combination satisfies the threshold without additional independent signers. This is why 2-of-3 collaborative setups (user + user + system) are stronger than they might appear: the operator + one user device is still only 2 keys, and the wallet still requires the third.

Loss of Sigvault as a Going Concern

Sigvault, the company, ceases to exist. Domain expires, infrastructure is shut down, code escrow trigger conditions are met.

Mitigations. All critical client code is open source and distributed. The wallet descriptor is portable and can be loaded into other Bitcoin wallet software (Sparrow, Electrum, Bitcoin Core) for spending. System-managed keys are held under code escrow. See Recovery Without Sigvault.

Quantum Adversary

An attacker with a sufficiently capable quantum computer that can break ECDSA / Schnorr.

Mitigations. None at the current Bitcoin protocol level — this affects all Bitcoin wallets equally. Sigvault will follow Bitcoin protocol upgrades for post-quantum signatures when they are standardized. Until then, the standard mitigation is to avoid address reuse, which Sigvault enforces by default.

Cryptographic Invariants

The open-source cryptographic backend service is designed so that the following invariants hold by construction. A reviewer reading the code should be able to verify each.

No signature without policy satisfaction. The signing pipeline refuses to emit a signature unless the requested transaction satisfies a declared spending condition of the wallet, including threshold, signers, and time lock.
System-managed keys never leave the service in plaintext. Decryption happens only inside the signing operation and the plaintext key is not written to disk, logs, or network.
PSBTs are validated before signing. Inputs and outputs are checked against the wallet’s known descriptors; the service refuses to sign PSBTs whose inputs do not belong to the wallet or whose change outputs are not derived from the wallet’s own keys.
Audit log entries cover every operation. Every wallet creation, signing request, and key access produces a signed log entry that is independently verifiable.
Hardware wallet path verification. When a hardware wallet contributes a signature to a multi-key wallet, the cryptographic service verifies that the contributed public key matches the registered descriptor before accepting the partial signature.

These invariants are enforced in code, not by policy or process. They cannot be silently bypassed by the business backend.

Recovery Without Sigvault

A wallet’s funds must be recoverable even if Sigvault, the company, no longer exists. This is not a feature toggle — it is a property of how Sigvault uses standard Bitcoin output scripts.

For non-custodial wallets, recovery requires:

The wallet descriptor (a standard Bitcoin output descriptor — text, save it offline)
The seed phrases for each hardware wallet involved

With these, you can load the wallet into any compatible Bitcoin software (Bitcoin Core, Sparrow, Electrum, Specter Desktop) and sign transactions independently.

For collaborative wallets (mix of user and system keys), recovery requires the same plus access to system-managed key material, which Sigvault holds under code escrow with named release triggers. The released material is in standard formats (BIP39 mnemonics, BIP32 derivations) and can be loaded into any compatible wallet.

For purely custodial wallets, recovery depends on Sigvault’s continuity plan being executed, since the user does not hold the keys. This is a known trade-off of custodial setups.

We recommend treating descriptor backup as part of any wallet’s setup process and verifying recovery on a small test balance before committing significant value.

Residual Risks

Honest threat modeling names what is not mitigated. The following risks remain.

Custodial wallet operator compromise

Wallets configured with a system-managed key as the sole signer (custodial hot wallets) are exposed to a worst-case Sigvault operator compromise. This trade-off is the cost of automated signing. Use this configuration only for balances where that risk is acceptable.

Single-vendor hardware risk

A wallet configured with multiple devices from the same manufacturer remains exposed to a single firmware vulnerability. The descriptor format and our wallet templates support multi-vendor setups; users are responsible for choosing them.

User verification failure

A user who approves a transaction on their hardware wallet without checking the destination address and amount on the device’s own screen can be deceived by a compromised desktop application. Hardware wallet vendors have invested heavily in making this verification clear; the user must still perform it.

Metadata exposure

The business backend observes operational metadata: when transactions are signed, which wallets are active, IP addresses, sign-in patterns. This metadata is not protected by the cryptographic invariants. Users with strong privacy requirements should evaluate what metadata is acceptable.

Time-lock race conditions

Recovery paths in taproot vaults become spendable by anyone holding the recovery quorum once the time lock expires. Wallet owners must keep primary spending paths active to reset the lock and prevent unintended recovery activation.

Side-channel attacks on hardware

Side-channel attacks on hardware wallets (timing, power analysis, glitching) are out of Sigvault’s control. We rely on hardware vendor security claims.

Software supply chain

Compromise of upstream open-source dependencies could affect the cryptographic backend. We pin dependencies, audit cryptographic libraries, and reproduce builds, but cannot eliminate this risk entirely.

What This Document Does Not Replace

This threat model is one document in a larger trust foundation. It is most useful read alongside:

The open-source repositories for the desktop app and cryptographic backend service
The published third-party security audit report and its remediation summary
The signed audit log specification
The continuity plan describing what happens if Sigvault ceases operations
The bug bounty program terms

If you are evaluating Sigvault for institutional custody, please request a copy of the most recent audit report and continuity documentation directly.

Reporting a Security Issue

Please report suspected vulnerabilities through the bug bounty program rather than public channels. For sensitive disclosures that should not go through a third party, contact security@sigvault.org with an encrypted message — the PGP key is published on the security page of sigvault.org.

We commit to acknowledging receipt within one business day and providing a substantive response within five business days.