BIP 370 is the Bitcoin Improvement Proposal that updates the PSBT format with a newer version. It extends the transaction container and field handling used for partially signed Bitcoin transactions, improving how software exchanges signing data and transaction metadata.
What BIP 370 Changes
BIP 370 updates the Bitcoin PSBT format by introducing a newer version of the transaction container and field handling. The practical effect is a cleaner way for software to exchange partially signed transaction data and related metadata during collaborative signing workflows.
That matters because PSBT is designed for coordination between wallets, signers, and transaction-building tools that may not share private keys. When the container format changes, all participants need to interpret the same structure consistently, or signing and finalization can fail even when the underlying Bitcoin transaction is valid.
Why the PSBT Format Matters
PSBT exists to separate transaction construction from signature production. It lets different tools add or consume the data they need without exposing the full signing context to every participant, which is especially useful in multi-step approval flows and hardware-assisted signing.
BIP 370 is therefore best understood as a format evolution, not a change to Bitcoin consensus rules. It affects how software packages, forwards, and preserves the metadata required for safe signing, which makes compatibility and parsing discipline more important than raw transaction logic.
Compatibility and Interoperability
Any newer container version creates an interoperability boundary. Software that reads, writes, or relays PSBTs must understand the updated structure, or it may strip fields, reject valid input, or mis-handle metadata that later signers depend on.
This is particularly important in mixed ecosystems where wallets, coordinators, custody tools, and signing devices are not released together. The safest assumption is that every participant should be tested against the exact PSBT version and field semantics it will see in production, rather than relying on implied backward compatibility.
Security and Operational Consequences
Format handling is a security issue when malformed or unexpected transaction containers cause a signer to approve the wrong transaction, ignore important metadata, or accept data it should have rejected. In Bitcoin workflows, the main failure mode is not usually consensus violation, but human or software confusion at the signing boundary.
Operationally, the update can also surface hidden assumptions in custom parsers, policy engines, and signing coordinators. A tool that was safe with older PSBT data may become unreliable if it does not validate the newer field model with equal strictness.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PSBT workflows depend on protecting signing material across tools and participants. |
| AC-3 — Access Enforcement | Collaborative signing depends on enforcing who can create, modify, and finalize transaction data. | |
| Recommendation — Manage signing secrets and related credentials so PSBT handling does not expose authentication material. Enforce access rules around PSBT creation, modification, and final signing steps. | ||
| CIS Controls v8 | CIS-5 — Account Management | Bitcoin signing workflows rely on controlled use of accounts and privileges in coordinating tools. |
| Recommendation — Restrict and review accounts that can authorise or alter PSBT signing workflows. | ||
| OWASP ASVS | V8 — Authorization | PSBT processing tools must only allow authorized transaction edits and signing actions. |
| Recommendation — Verify that only authorized actors can change PSBT state or submit signing data. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets are authenticated and authorized before access is granted | PSBT ecosystems need authenticated participants before signing or transaction data exchange. |
| Recommendation — Authenticate participants before they can exchange or approve PSBT data. | ||
Practitioner Guidance
Why practitioners should care: Treat PSBT version support as an explicit compatibility requirement in any signing stack that handles collaborative Bitcoin transactions. If one component lags behind, transaction assembly and finalization can become brittle even when the rest of the system is functioning correctly.
What to watch for: Review wallet, signer, and coordinator behavior whenever PSBT support changes, especially around field preservation, input validation, and unknown-data handling. The goal is to avoid silent translation errors that alter what later participants see.
Practitioner takeaway: Use the newer PSBT version only where every participant in the workflow can reliably parse and preserve it end to end.
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org