{
  "release": {
    "id": "bitcoin-safe-open-threat-model",
    "version": "1.0.0",
    "status": "current",
    "publishedAt": "2026-08-28",
    "reviewedAt": "2026-08-28",
    "canonicalPath": "/research/bitcoin-threat-model/1.0.0",
    "currentPath": "/research/bitcoin-threat-model",
    "license": {
      "id": "CC-BY-4.0",
      "name": "Creative Commons Attribution 4.0 International",
      "url": "https://creativecommons.org/licenses/by/4.0/",
      "scope": "The threat-model prose, taxonomy, relationship data, and generated research files are licensed under CC BY 4.0. Application code and unrelated site content are outside this notice."
    },
    "repositoryUrl": "https://github.com/kevinkinnett/bitcoinsafe/tree/main/public/research/bitcoin-threat-model/1.0.0",
    "correctionUrl": "https://github.com/kevinkinnett/bitcoinsafe/issues"
  },
  "language": "en",
  "title": "BitcoinSafe Open Bitcoin Custody Threat Model",
  "summary": "A public framework for examining how operational failures and attacks can cause unauthorized spending, loss of recovery capability, privacy exposure, or a breakdown in continuity. It links each threat to controls, expected evidence, and remaining risk.",
  "audience": "People operating a personal Bitcoin custody setup, educators explaining self-custody, and developers who need stable public IDs for safety guidance. The model is not tailored to a person, balance, jurisdiction, or adversary.",
  "methodology": "The model follows a scope, threat, response, and review sequence. Priorities describe how directly a stated condition can lead to loss; they do not estimate probability. Controls reduce specific failure paths but never establish that a wallet or setup is safe.",
  "certificationBoundary": "This publication is a reasoning framework, not a safety score, audit, warranty, product endorsement, or certification. Public documentation can be incomplete, implementations can contain defects, and correctly applied controls still leave residual risk.",
  "assumptions": [
    {
      "id": "assumption-bitcoin-key-authority",
      "title": "Spending authority follows valid keys and policy",
      "description": "A party that can satisfy the wallet policy can authorize a spend. Losing every valid recovery path can make funds inaccessible even when the Bitcoin network continues to operate."
    },
    {
      "id": "assumption-hosts-can-fail",
      "title": "General-purpose devices and services can fail or be compromised",
      "description": "Phones, computers, browser sessions, cloud accounts, exchanges, coordinators, and communication channels are treated as fallible rather than trusted by default."
    },
    {
      "id": "assumption-human-operation",
      "title": "Human error is part of the operating environment",
      "description": "The model includes mistakes in backup handling, recovery, transaction review, access control, documentation, and handoff. It does not assume a perfectly trained operator."
    },
    {
      "id": "assumption-public-evidence",
      "title": "Only inspectable evidence supports a published control claim",
      "description": "A control is documented only to the level supported by public specifications, vendor documentation, reproducible records, or an identified review. Absence of a disclosed problem is not proof of safety."
    }
  ],
  "assets": [
    {
      "id": "asset-spending-authority",
      "title": "Spending authority",
      "description": "Private keys, signing devices, passphrases, policies, and quorum components that can authorize a transaction."
    },
    {
      "id": "asset-recovery-capability",
      "title": "Recovery capability",
      "description": "Backups, wallet metadata, derivation information, instructions, and tested procedures required to restore access."
    },
    {
      "id": "asset-transaction-intent",
      "title": "Transaction intent",
      "description": "The intended recipient, amount, fee, change, inputs, and signing policy for a proposed spend."
    },
    {
      "id": "asset-privacy-metadata",
      "title": "Wallet privacy and metadata",
      "description": "Addresses, extended public keys, balances, transaction history, counterparties, and ownership relationships."
    },
    {
      "id": "asset-operational-continuity",
      "title": "Operational continuity",
      "description": "The ability of an authorized person to understand, maintain, recover, and transfer the setup over time."
    }
  ],
  "categories": [
    {
      "id": "custody",
      "order": 1,
      "title": "Custody authority",
      "summary": "Who can authorize spending, and which parties or components must be trusted to remain available and honest."
    },
    {
      "id": "backup",
      "order": 2,
      "title": "Backup resilience",
      "summary": "Whether recovery material survives loss and remains unavailable to unauthorized people."
    },
    {
      "id": "recovery",
      "order": 3,
      "title": "Recovery readiness",
      "summary": "Whether the keys, wallet context, tools, and procedure can restore the intended wallet before an emergency."
    },
    {
      "id": "access",
      "order": 4,
      "title": "Access protection",
      "summary": "How provider accounts, general-purpose devices, wallet software, and signing interfaces resist takeover or compromise."
    },
    {
      "id": "transaction",
      "order": 5,
      "title": "Transaction verification",
      "summary": "Whether the signer can independently confirm what will be authorized before a transaction becomes irreversible."
    },
    {
      "id": "continuity",
      "order": 6,
      "title": "Continuity and succession",
      "summary": "Whether an authorized successor can locate the right non-secret information and follow a tested process without exposing every secret together."
    }
  ],
  "severityTerms": [
    {
      "id": "high",
      "label": "High attention",
      "definition": "The stated condition can directly enable unauthorized spending or permanent loss of access. This label does not estimate how likely the event is."
    },
    {
      "id": "important",
      "label": "Important",
      "definition": "The condition can block recovery, weaken verification, or make another failure materially harder to contain."
    },
    {
      "id": "contextual",
      "label": "Context dependent",
      "definition": "The consequence depends strongly on the custody model, value at risk, adversary, jurisdiction, or operating frequency. It still requires an explicit decision."
    }
  ],
  "threats": [
    {
      "id": "threat-custody-provider-control",
      "categoryId": "custody",
      "priority": "high",
      "assetIds": [
        "asset-spending-authority",
        "asset-operational-continuity"
      ],
      "sourceIds": [
        "source-bitcoin-wallet-guide",
        "source-nist-risk-assessment"
      ],
      "title": "A provider controls withdrawal or signing",
      "scenario": "An exchange, custodian, hosted wallet, or policy service can delay, refuse, redirect, or lose the ability to authorize a withdrawal.",
      "rationale": "The operator does not hold every key needed to spend. Provider solvency, account controls, policy, jurisdiction, and availability remain part of the custody boundary."
    },
    {
      "id": "threat-custody-signer-compromise",
      "categoryId": "custody",
      "priority": "high",
      "assetIds": [
        "asset-spending-authority",
        "asset-privacy-metadata"
      ],
      "sourceIds": [
        "source-bitcoin-wallet-guide",
        "source-bip32",
        "source-bip39"
      ],
      "title": "Enough signing authority is stolen or copied",
      "scenario": "An attacker obtains a private key, recovery phrase, passphrase, signing device, or enough quorum components to satisfy the wallet policy.",
      "rationale": "Bitcoin validates authorization, not the identity or intent of the person presenting a valid signature. Separation only helps while the policy threshold remains uncompromised."
    },
    {
      "id": "threat-backup-unavailable",
      "categoryId": "backup",
      "priority": "high",
      "assetIds": [
        "asset-recovery-capability",
        "asset-operational-continuity"
      ],
      "sourceIds": [
        "source-bip32",
        "source-bip39",
        "source-cisa-backups"
      ],
      "title": "Recovery material is missing or unreadable",
      "scenario": "Loss, fire, water, corrosion, accidental disposal, memory failure, or a single shared location removes every usable backup.",
      "rationale": "Deterministic wallet recovery depends on retaining the required seed or key material. A backup that has not been checked may fail only after the signing device is gone."
    },
    {
      "id": "threat-backup-secret-exposure",
      "categoryId": "backup",
      "priority": "high",
      "assetIds": [
        "asset-spending-authority",
        "asset-privacy-metadata"
      ],
      "sourceIds": [
        "source-bip32",
        "source-bip39"
      ],
      "title": "A backup exposes signing secrets",
      "scenario": "Recovery words, private keys, or passphrases enter a photo, cloud document, ordinary computer, shared note, or location accessible to an unauthorized person.",
      "rationale": "A deterministic seed can derive the wallet’s private keys. Redundancy improves availability but also creates more copies that require confidentiality and access control."
    },
    {
      "id": "threat-recovery-not-rehearsed",
      "categoryId": "recovery",
      "priority": "important",
      "assetIds": [
        "asset-recovery-capability",
        "asset-operational-continuity"
      ],
      "sourceIds": [
        "source-cisa-backups",
        "source-nist-contingency"
      ],
      "title": "The recovery procedure has not been rehearsed",
      "scenario": "During device loss or failure, the operator discovers an incorrect word, forgotten passphrase, incompatible wallet, missing signer, or procedure they cannot complete.",
      "rationale": "Possessing backup material does not prove that the complete wallet can be reconstructed. A controlled rehearsal can reveal procedural and compatibility failures before funds depend on recovery."
    },
    {
      "id": "threat-recovery-wallet-context-missing",
      "categoryId": "recovery",
      "priority": "important",
      "assetIds": [
        "asset-recovery-capability",
        "asset-privacy-metadata"
      ],
      "sourceIds": [
        "source-bip380"
      ],
      "title": "Keys survive but wallet context is missing",
      "scenario": "A recovery has the seed or keys but lacks the script type, derivation path, descriptor, quorum policy, cosigner keys, or coordinator information needed to find and spend the intended outputs.",
      "rationale": "BIP 380 documents why private keys alone can be insufficient to reconstruct the scripts and derivation paths a wallet used, especially for non-default or multisignature policies."
    },
    {
      "id": "threat-access-provider-account-takeover",
      "categoryId": "access",
      "priority": "high",
      "assetIds": [
        "asset-spending-authority",
        "asset-recovery-capability",
        "asset-privacy-metadata"
      ],
      "sourceIds": [
        "source-nist-authentication"
      ],
      "title": "A provider account is taken over",
      "scenario": "Phishing, password reuse, session theft, weak recovery, or compromised email lets an attacker control an exchange, hosted wallet, cloud backup, or communication account.",
      "rationale": "Account controls can become part of custody, backup confidentiality, or continuity. Manually entered one-time codes are not phishing-resistant under NIST’s definition."
    },
    {
      "id": "threat-access-signing-environment-compromise",
      "categoryId": "access",
      "priority": "high",
      "assetIds": [
        "asset-spending-authority",
        "asset-transaction-intent",
        "asset-privacy-metadata"
      ],
      "sourceIds": [
        "source-bitcoin-core-offline-signing",
        "source-bip174"
      ],
      "title": "The signing environment is compromised",
      "scenario": "Malware, a malicious update, remote access, a counterfeit application, or a modified device attempts to expose keys or alter transaction data.",
      "rationale": "Separating signing from a networked host reduces key-exfiltration opportunities, but the signer, transfer channel, firmware, and review process remain trust boundaries."
    },
    {
      "id": "threat-transaction-destination-substitution",
      "categoryId": "transaction",
      "priority": "high",
      "assetIds": [
        "asset-transaction-intent",
        "asset-spending-authority"
      ],
      "sourceIds": [
        "source-bip174",
        "source-bitcoin-core-offline-signing"
      ],
      "title": "The destination or amount is substituted",
      "scenario": "A compromised host, clipboard, QR code, payment request, or coordinator presents transaction details that differ from the operator’s intent.",
      "rationale": "A valid signature authorizes the transaction actually presented to the signer. Independent review must cover the destination, amount, fee, and change using a trusted channel or display."
    },
    {
      "id": "threat-transaction-incomplete-signing-context",
      "categoryId": "transaction",
      "priority": "important",
      "assetIds": [
        "asset-transaction-intent",
        "asset-spending-authority"
      ],
      "sourceIds": [
        "source-bip174"
      ],
      "title": "The signer lacks enough context to verify the spend",
      "scenario": "The signing device or person cannot reliably identify inputs, change, fees, wallet policy, or whether another system modified the proposed transaction.",
      "rationale": "PSBT standardizes data exchange between transaction roles, but a format alone does not prove that a signer displayed or checked every decision-relevant field."
    },
    {
      "id": "threat-continuity-operator-unavailability",
      "categoryId": "continuity",
      "priority": "important",
      "assetIds": [
        "asset-operational-continuity",
        "asset-recovery-capability"
      ],
      "sourceIds": [
        "source-nist-contingency"
      ],
      "title": "The only informed operator is unavailable",
      "scenario": "Death, incapacity, travel, coercion, conflict, or simple loss of contact leaves authorized successors unable to locate the wallet or understand the recovery process.",
      "rationale": "Technical recovery material does not communicate legal authority, roles, locations, dependencies, or the order of operations. Continuity requires documented and tested handoff procedures."
    },
    {
      "id": "threat-continuity-secret-concentration",
      "categoryId": "continuity",
      "priority": "high",
      "assetIds": [
        "asset-spending-authority",
        "asset-operational-continuity",
        "asset-privacy-metadata"
      ],
      "sourceIds": [
        "source-nist-contingency",
        "source-bip32"
      ],
      "title": "A continuity document concentrates every secret",
      "scenario": "One document, safe, lawyer, relative, or digital account contains enough recovery material and instructions to authorize spending without another independent control.",
      "rationale": "Continuity can improve availability while weakening confidentiality. A useful handoff explains roles and locations without turning one discoverable record into complete spending authority."
    }
  ],
  "mitigations": [
    {
      "id": "mitigation-define-custody-boundary",
      "sourceIds": [
        "source-nist-risk-assessment",
        "source-bitcoin-wallet-guide"
      ],
      "title": "Write down the custody boundary",
      "action": "Identify every person, provider, device, key, policy, and recovery process that can authorize or block a spend. Decide which dependencies are acceptable before moving meaningful funds.",
      "limitation": "Documentation makes dependencies visible; it does not remove provider, legal, solvency, or implementation risk."
    },
    {
      "id": "mitigation-isolate-signing-keys",
      "sourceIds": [
        "source-bitcoin-core-offline-signing",
        "source-bip174"
      ],
      "title": "Isolate enough signing authority",
      "action": "Keep private keys away from ordinary networked devices when the operating model supports it. For quorum wallets, separate signers so one compromise does not satisfy the policy.",
      "limitation": "Isolation adds transfer, update, verification, and recovery steps. It does not prove that the signer or firmware is trustworthy."
    },
    {
      "id": "mitigation-redundant-offline-backups",
      "sourceIds": [
        "source-cisa-backups",
        "source-bip32",
        "source-bip39"
      ],
      "title": "Maintain checked backups across failure boundaries",
      "action": "Keep the required recovery material in more than one protected location when the loss scenario warrants it. Check legibility, completeness, and access without exposing the secret to an online system.",
      "limitation": "Every extra copy expands the confidentiality and access-control problem. Geographic separation can also complicate timely recovery."
    },
    {
      "id": "mitigation-separate-secret-material",
      "sourceIds": [
        "source-bip32",
        "source-bip39",
        "source-nist-contingency"
      ],
      "title": "Separate secrets from instructions and from each other",
      "action": "Do not put a seed, passphrase, PIN, and complete recovery procedure in one ordinary document or online account. Use distinct access boundaries that match the wallet policy.",
      "limitation": "Separation can create lockout if dependencies are undocumented or if an authorized person cannot reunite the required parts."
    },
    {
      "id": "mitigation-rehearse-recovery",
      "sourceIds": [
        "source-cisa-backups",
        "source-nist-contingency"
      ],
      "title": "Rehearse recovery before an emergency",
      "action": "Use a controlled procedure, a spare or reset device, and a non-valuable test wallet where appropriate. Confirm the expected wallet, policy, addresses, and ability to sign without entering secrets into an untrusted device.",
      "limitation": "A rehearsal proves only the tested path at that time. Software, devices, people, locations, and documentation can change afterward."
    },
    {
      "id": "mitigation-preserve-wallet-context",
      "sourceIds": [
        "source-bip380"
      ],
      "title": "Preserve non-secret wallet context",
      "action": "Record the wallet type, script policy, derivation information, master fingerprints, quorum, coordinator requirements, and tested restoration software without combining them with every spending secret.",
      "limitation": "Descriptors and extended public keys can expose addresses and transaction history. Treat them as privacy-sensitive even when they cannot spend alone."
    },
    {
      "id": "mitigation-phishing-resistant-access",
      "sourceIds": [
        "source-nist-authentication"
      ],
      "title": "Use phishing-resistant account access where available",
      "action": "Protect provider, email, and cloud accounts with unique credentials and a cryptographic authenticator bound to the real service domain when supported. Review account-recovery paths as part of the same boundary.",
      "limitation": "Strong authentication does not address provider insolvency, malicious insiders, compromised endpoints, or a flawed withdrawal process."
    },
    {
      "id": "mitigation-harden-signing-environment",
      "sourceIds": [
        "source-bitcoin-core-offline-signing",
        "source-nist-risk-assessment"
      ],
      "title": "Reduce trust in the networked signing environment",
      "action": "Use maintained software from authenticated sources, limit remote access and unnecessary applications, isolate keys when justified, and keep an independent way to verify transaction intent.",
      "limitation": "Operational hardening reduces exposure but cannot establish that every dependency, update, library, or device is free of defects."
    },
    {
      "id": "mitigation-verify-on-trusted-display",
      "sourceIds": [
        "source-bip174",
        "source-bitcoin-core-external-signer"
      ],
      "title": "Verify transaction intent on an independent display",
      "action": "Before signing, compare the recipient, amount, fee, change, network, and policy with the original intent on a signer or channel that does not rely solely on the transaction-creating host.",
      "limitation": "A display can omit fields, present confusing data, or itself be compromised. Verification is only as good as the independent reference and the operator’s review."
    },
    {
      "id": "mitigation-separate-transaction-roles",
      "sourceIds": [
        "source-bip174",
        "source-bitcoin-core-offline-signing"
      ],
      "title": "Separate transaction creation, signing, and broadcast where useful",
      "action": "Use a standard interchange format such as PSBT when multiple systems or signers must cooperate. Require each signer to validate the policy and relevant fields before adding a signature.",
      "limitation": "Role separation increases coordination and metadata handling. PSBT can contain privacy-sensitive wallet information and does not force a device to display every relevant field."
    },
    {
      "id": "mitigation-document-continuity-roles",
      "sourceIds": [
        "source-nist-contingency"
      ],
      "title": "Document roles, dependencies, and locations without recording secrets",
      "action": "Record who should act, what non-secret records exist, where separate materials are held, which professionals or providers are involved, and how authority is verified. Keep spending secrets outside the continuity document.",
      "limitation": "Operational documentation is not an estate plan and may not create legal authority. Jurisdiction-specific legal and tax advice remains separate."
    },
    {
      "id": "mitigation-rehearse-continuity",
      "sourceIds": [
        "source-nist-contingency"
      ],
      "title": "Rehearse the continuity handoff",
      "action": "Have an authorized participant explain or simulate the process with non-secret records. Confirm contacts, locations, dependencies, device disposition, and escalation paths on a dated schedule.",
      "limitation": "A rehearsal can expose sensitive relationships and may become stale after family, legal, provider, device, or wallet changes."
    }
  ],
  "evidenceExpectations": [
    {
      "id": "evidence-custody-boundary",
      "title": "Custody boundary evidence",
      "description": "A current inventory of required signers, providers, policies, recovery paths, and blocking dependencies. Marketing claims alone do not establish control."
    },
    {
      "id": "evidence-backup-check",
      "title": "Backup evidence",
      "description": "A dated check that required material exists, remains legible, is separated across the intended failure boundaries, and has not been entered into an untrusted system."
    },
    {
      "id": "evidence-recovery-rehearsal",
      "title": "Recovery evidence",
      "description": "A dated record of the tested recovery path, wallet identity check, tools used, policy reconstructed, problems found, and remediation. It must not contain the recovery secret itself."
    },
    {
      "id": "evidence-access-controls",
      "title": "Access-control evidence",
      "description": "Documented account-recovery methods, authenticator type, device and software provenance, update process, and removal of obsolete access."
    },
    {
      "id": "evidence-transaction-verification",
      "title": "Transaction-verification evidence",
      "description": "A repeatable procedure identifying which fields each signer checks, the independent source of intent, policy validation, and the point at which broadcast is allowed."
    },
    {
      "id": "evidence-continuity-rehearsal",
      "title": "Continuity evidence",
      "description": "A dated non-secret role and location inventory, named owner for each follow-up, rehearsal record, and review trigger after material family, legal, provider, or wallet changes."
    }
  ],
  "residualRisks": [
    {
      "id": "residual-custody",
      "title": "Custody dependencies remain",
      "description": "Keys, devices, people, providers, and policies can fail together or behave differently from their documentation. More independence usually adds operating complexity."
    },
    {
      "id": "residual-backup",
      "title": "Availability and secrecy remain in tension",
      "description": "More copies can survive more loss events but create more opportunities for discovery, coercion, mishandling, or stale records."
    },
    {
      "id": "residual-recovery",
      "title": "A past rehearsal cannot guarantee a future recovery",
      "description": "Devices, software compatibility, people, memory, documentation, and wallet state can change after a successful test."
    },
    {
      "id": "residual-access",
      "title": "Strong access controls do not secure every dependency",
      "description": "Endpoints, support processes, service insiders, firmware, physical access, and software supply chains remain possible failure paths."
    },
    {
      "id": "residual-transaction",
      "title": "Verification can still fail at the human or display layer",
      "description": "A signer may omit important information, the reference may be compromised, or the operator may approve confusing or unexpected data."
    },
    {
      "id": "residual-continuity",
      "title": "Succession combines technical and legal uncertainty",
      "description": "A technically sound handoff may conflict with law, tax, family circumstances, provider rules, or the current wishes of the owner."
    }
  ],
  "relationships": [
    {
      "threatId": "threat-custody-provider-control",
      "mitigationIds": [
        "mitigation-define-custody-boundary",
        "mitigation-phishing-resistant-access"
      ],
      "evidenceExpectationIds": [
        "evidence-custody-boundary",
        "evidence-access-controls"
      ],
      "residualRiskIds": [
        "residual-custody",
        "residual-access"
      ]
    },
    {
      "threatId": "threat-custody-signer-compromise",
      "mitigationIds": [
        "mitigation-isolate-signing-keys",
        "mitigation-separate-secret-material"
      ],
      "evidenceExpectationIds": [
        "evidence-custody-boundary",
        "evidence-backup-check"
      ],
      "residualRiskIds": [
        "residual-custody",
        "residual-backup"
      ]
    },
    {
      "threatId": "threat-backup-unavailable",
      "mitigationIds": [
        "mitigation-redundant-offline-backups",
        "mitigation-rehearse-recovery"
      ],
      "evidenceExpectationIds": [
        "evidence-backup-check",
        "evidence-recovery-rehearsal"
      ],
      "residualRiskIds": [
        "residual-backup",
        "residual-recovery"
      ]
    },
    {
      "threatId": "threat-backup-secret-exposure",
      "mitigationIds": [
        "mitigation-separate-secret-material",
        "mitigation-redundant-offline-backups"
      ],
      "evidenceExpectationIds": [
        "evidence-backup-check"
      ],
      "residualRiskIds": [
        "residual-backup"
      ]
    },
    {
      "threatId": "threat-recovery-not-rehearsed",
      "mitigationIds": [
        "mitigation-rehearse-recovery",
        "mitigation-preserve-wallet-context"
      ],
      "evidenceExpectationIds": [
        "evidence-recovery-rehearsal"
      ],
      "residualRiskIds": [
        "residual-recovery"
      ]
    },
    {
      "threatId": "threat-recovery-wallet-context-missing",
      "mitigationIds": [
        "mitigation-preserve-wallet-context",
        "mitigation-rehearse-recovery"
      ],
      "evidenceExpectationIds": [
        "evidence-recovery-rehearsal"
      ],
      "residualRiskIds": [
        "residual-recovery",
        "residual-backup"
      ]
    },
    {
      "threatId": "threat-access-provider-account-takeover",
      "mitigationIds": [
        "mitigation-phishing-resistant-access",
        "mitigation-define-custody-boundary"
      ],
      "evidenceExpectationIds": [
        "evidence-access-controls",
        "evidence-custody-boundary"
      ],
      "residualRiskIds": [
        "residual-access",
        "residual-custody"
      ]
    },
    {
      "threatId": "threat-access-signing-environment-compromise",
      "mitigationIds": [
        "mitigation-harden-signing-environment",
        "mitigation-isolate-signing-keys",
        "mitigation-verify-on-trusted-display"
      ],
      "evidenceExpectationIds": [
        "evidence-access-controls",
        "evidence-transaction-verification"
      ],
      "residualRiskIds": [
        "residual-access",
        "residual-transaction"
      ]
    },
    {
      "threatId": "threat-transaction-destination-substitution",
      "mitigationIds": [
        "mitigation-verify-on-trusted-display",
        "mitigation-separate-transaction-roles"
      ],
      "evidenceExpectationIds": [
        "evidence-transaction-verification"
      ],
      "residualRiskIds": [
        "residual-transaction"
      ]
    },
    {
      "threatId": "threat-transaction-incomplete-signing-context",
      "mitigationIds": [
        "mitigation-separate-transaction-roles",
        "mitigation-verify-on-trusted-display"
      ],
      "evidenceExpectationIds": [
        "evidence-transaction-verification"
      ],
      "residualRiskIds": [
        "residual-transaction"
      ]
    },
    {
      "threatId": "threat-continuity-operator-unavailability",
      "mitigationIds": [
        "mitigation-document-continuity-roles",
        "mitigation-rehearse-continuity"
      ],
      "evidenceExpectationIds": [
        "evidence-continuity-rehearsal"
      ],
      "residualRiskIds": [
        "residual-continuity",
        "residual-recovery"
      ]
    },
    {
      "threatId": "threat-continuity-secret-concentration",
      "mitigationIds": [
        "mitigation-document-continuity-roles",
        "mitigation-separate-secret-material",
        "mitigation-rehearse-continuity"
      ],
      "evidenceExpectationIds": [
        "evidence-continuity-rehearsal",
        "evidence-backup-check"
      ],
      "residualRiskIds": [
        "residual-continuity",
        "residual-backup"
      ]
    }
  ],
  "exclusions": [
    {
      "id": "exclusion-market-risk",
      "title": "Market and price risk",
      "description": "The model does not forecast price, liquidity, tax treatment, or the suitability of holding bitcoin."
    },
    {
      "id": "exclusion-consensus-network",
      "title": "Bitcoin consensus and network security",
      "description": "Consensus failures, mining attacks, protocol defects, and network partition analysis are outside this custody-operations model."
    },
    {
      "id": "exclusion-product-certification",
      "title": "Product certification or ranking",
      "description": "The model does not certify a hardware wallet, software wallet, exchange, custodian, multisignature service, or recovery provider."
    },
    {
      "id": "exclusion-personalized-assessment",
      "title": "Personalized risk determination",
      "description": "No priority in this publication accounts for a reader’s balance, skills, adversaries, location, family, or operating frequency."
    },
    {
      "id": "exclusion-legal-advice",
      "title": "Legal, tax, and estate advice",
      "description": "Continuity controls describe operations only. They do not create legal authority or replace qualified advice in the relevant jurisdiction."
    }
  ],
  "sources": [
    {
      "id": "source-nist-risk-assessment",
      "title": "NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments",
      "publisher": "National Institute of Standards and Technology",
      "url": "https://doi.org/10.6028/NIST.SP.800-30r1",
      "kind": "government-standard",
      "checkedAt": "2026-08-28",
      "note": "Used for explicit scope, assumptions, threat sources, uncertainty, and review discipline. BitcoinSafe does not copy NIST probability scales."
    },
    {
      "id": "source-owasp-threat-modeling",
      "title": "OWASP Threat Modeling Cheat Sheet",
      "publisher": "OWASP Foundation",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html",
      "kind": "authoritative-guidance",
      "checkedAt": "2026-08-28",
      "note": "Used for the scope, identify, respond, and review sequence and for documenting actionable mitigations."
    },
    {
      "id": "source-bitcoin-wallet-guide",
      "title": "Bitcoin Developer Guide: Wallets",
      "publisher": "Bitcoin Developer Documentation",
      "url": "https://developer.bitcoin.org/devguide/wallets.html",
      "kind": "bitcoin-core-documentation",
      "checkedAt": "2026-08-28",
      "note": "Used for the separation of key distribution, signing, and network functions and the role of private keys in spending."
    },
    {
      "id": "source-bip32",
      "title": "BIP 32: Hierarchical Deterministic Wallets",
      "publisher": "Bitcoin Improvement Proposals",
      "url": "https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki",
      "kind": "bitcoin-specification",
      "checkedAt": "2026-08-28",
      "note": "Used for deterministic key derivation and the consequence of exposing or losing root key material."
    },
    {
      "id": "source-bip39",
      "title": "BIP 39: Mnemonic code for generating deterministic keys",
      "publisher": "Bitcoin Improvement Proposals",
      "url": "https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki",
      "kind": "bitcoin-specification",
      "checkedAt": "2026-08-28",
      "note": "Used only to describe mnemonic recovery material and optional passphrase behavior. The model does not claim BIP 39 is required for every wallet."
    },
    {
      "id": "source-bip174",
      "title": "BIP 174: Partially Signed Bitcoin Transaction Format",
      "publisher": "Bitcoin Improvement Proposals",
      "url": "https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki",
      "kind": "bitcoin-specification",
      "checkedAt": "2026-08-28",
      "note": "Used for transaction-role separation, offline signing, signer inputs, and PSBT metadata boundaries."
    },
    {
      "id": "source-bip380",
      "title": "BIP 380: Output Script Descriptors General Operation",
      "publisher": "Bitcoin Improvement Proposals",
      "url": "https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki",
      "kind": "bitcoin-specification",
      "checkedAt": "2026-08-28",
      "note": "Used for the recovery importance of script type, derivation paths, keys, and descriptor checksums beyond private keys alone."
    },
    {
      "id": "source-bitcoin-core-offline-signing",
      "title": "Bitcoin Core Offline Signing Tutorial",
      "publisher": "Bitcoin Core",
      "url": "https://github.com/bitcoin/bitcoin/blob/master/doc/offline-signing-tutorial.md",
      "kind": "bitcoin-core-documentation",
      "checkedAt": "2026-08-28",
      "note": "Used for the documented security purpose and operational boundary of offline PSBT signing."
    },
    {
      "id": "source-bitcoin-core-external-signer",
      "title": "Bitcoin Core External Signer Documentation",
      "publisher": "Bitcoin Core",
      "url": "https://github.com/bitcoin/bitcoin/blob/master/doc/external-signer.md",
      "kind": "bitcoin-core-documentation",
      "checkedAt": "2026-08-28",
      "note": "Used for external-signer identity checks, descriptor matching, and address display behavior."
    },
    {
      "id": "source-nist-authentication",
      "title": "NIST SP 800-63B-4: Authentication and Authenticator Management",
      "publisher": "National Institute of Standards and Technology",
      "url": "https://pages.nist.gov/800-63-4/sp800-63b.html",
      "kind": "government-standard",
      "checkedAt": "2026-08-28",
      "note": "Used for phishing resistance, verifier binding, authenticator controls, and the limit of manually entered one-time codes."
    },
    {
      "id": "source-cisa-backups",
      "title": "#StopRansomware Guide",
      "publisher": "Cybersecurity and Infrastructure Security Agency",
      "url": "https://www.cisa.gov/stopransomware/ransomware-guide",
      "kind": "government-standard",
      "checkedAt": "2026-08-28",
      "note": "Used for the general practice of offline backups and regular restoration testing. Bitcoin recovery adds separate secrecy constraints."
    },
    {
      "id": "source-nist-contingency",
      "title": "NIST SP 800-34 Rev. 1: Contingency Planning Guide",
      "publisher": "National Institute of Standards and Technology",
      "url": "https://doi.org/10.6028/NIST.SP.800-34r1",
      "kind": "government-standard",
      "checkedAt": "2026-08-28",
      "note": "Used for roles, recovery procedures, testing, validation, offsite material, and dated continuity records. It is general contingency guidance, not Bitcoin-specific advice."
    },
    {
      "id": "source-cc-by-4",
      "title": "Creative Commons Attribution 4.0 International",
      "publisher": "Creative Commons",
      "url": "https://creativecommons.org/licenses/by/4.0/",
      "kind": "license",
      "checkedAt": "2026-08-28",
      "note": "Defines the reuse terms for the scoped research prose and data."
    },
    {
      "id": "source-semver",
      "title": "Semantic Versioning 2.0.0",
      "publisher": "Semantic Versioning",
      "url": "https://semver.org/",
      "kind": "versioning-standard",
      "checkedAt": "2026-08-28",
      "note": "Defines the immutable release and major, minor, and patch version rules used by this model."
    }
  ],
  "changelog": [
    {
      "version": "1.0.0",
      "date": "2026-08-28",
      "summary": "Initial public release with six custody categories, 12 threats, 12 mitigations, evidence expectations, residual risks, assessment mappings, and localized research artifacts."
    }
  ]
}