BIP 174

What BIP 174 Specifies

BIP 174 standardises the Partially Signed Bitcoin Transaction, or PSBT, format. It gives wallets, signers, and transaction coordinators a shared representation for an in-progress Bitcoin transaction before all required signatures are present.

The important design idea is interoperability. A PSBT can carry the transaction data, metadata, and partial signature state needed for coordinated signing without forcing every participant to handle a fully finalised transaction too early. That reduces coordination friction across hardware wallets, software wallets, multisig workflows, and offline signing setups.

Why PSBT Exists

Before PSBT, wallets often had to exchange ad hoc formats or rely on application-specific signing flows. That created brittle integrations, made compatibility harder, and increased the chance that a signer would not have the context needed to validate what it was signing.

PSBT exists to make the handoff between transaction construction and transaction finalisation more predictable. The format preserves the information that downstream signers need, while still leaving the transaction incomplete until the right parties have reviewed and signed their parts. For a broad security baseline around authentication, access, and control enforcement, the NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference point for organisations that build signing or custody workflows on top of PSBT.

How PSBT Fits Signing Workflows

In practice, PSBT is a coordination object. One system can construct the transaction, another can inspect or enrich it, and one or more signers can add signatures without needing to reconstruct the full workflow state from scratch.

This is especially useful in multisignature and air-gapped environments, where the signing device may need a clean, structured packet rather than a raw transaction blob. The format is also helpful when different tools handle different stages of the same transaction lifecycle, because it reduces ambiguity about what has already been signed and what still needs approval.

When organisations want to understand the broader security posture around key handling, signing boundaries, and trust relationships in that workflow, the NIST SP 800-57 Key Management guidance is relevant because PSBT workflows often depend on careful protection of signing keys and signing authority.

Security Implications of PSBT

PSBT improves interoperability, but it does not make transaction review or signing safe by itself. A malformed, misleading, or incomplete PSBT can still trick a signer if the wallet UI, policy checks, or human review process is weak. The format also concentrates trust in the software that assembles and interprets the transaction fields.

That means the security value of PSBT depends on the surrounding controls: strong transaction validation, reliable metadata handling, and disciplined signing policy. In operational terms, the format is only as trustworthy as the tools that create, transport, inspect, and finalise it.

For teams that want to map this kind of transaction-handling risk to a broader control catalogue, the NIST Cybersecurity Framework 2.0 is a useful governance lens for identifying, protecting, detecting, responding, and recovering across the workflow.

Risk and Threat Considerations

PSBT reduces transaction-friction, but it also creates a structured object that can be tampered with, misread, or socially engineered if participants assume the packet is trustworthy. The main risk is not the format itself, but compromised transaction data, weak signer validation, or a workflow that accepts unsafe signing inputs without enough review.

Failure mechanism: An attacker or faulty integration alters transaction details, inserts misleading metadata, or feeds a signer a PSBT that appears legitimate but encodes an unwanted output, fee, or destination.

Impact: A signer may approve a transaction they did not intend to authorise, resulting in asset loss, policy violation, or irreversible on-chain transfer.

Practitioner Guidance

Why practitioners should care: PSBT is safest when each participating tool has a narrow, well-defined responsibility. Treat the format as a coordination layer, not as a guarantee that the transaction is correct or safe.

Common misunderstanding: Teams sometimes assume that a standardised PSBT removes the need for careful review. In reality, it only standardises how partial signing state is exchanged, while the responsibility for transaction legitimacy still sits with the wallet, signer, and approval process.

Practitioner takeaway: Use PSBT to make signing workflows interoperable, but keep validation, signer review, and key protection explicit and rigorous.