V3 Transaction (TRUC)

What Is a V3 Transaction (TRUC)?

A v3 transaction is a Bitcoin transaction that sets its version field (nVersion) to 3, opting into a stricter set of mempool relay rules called Topologically Restricted Until Confirmation (TRUC). These rules constrain how many unconfirmed descendants and ancestors a v3 transaction can have, and how large those descendants can be.

The purpose of these restrictions is to solve transaction pinning: a class of attacks where a malicious counterparty makes it prohibitively expensive to fee-bump a shared transaction. Pinning is especially dangerous for Lightning Network force-closes and other time-sensitive Layer 2 protocols, where delayed confirmation can lead to loss of funds.

TRUC was proposed by Gloria Zhao and formalized in BIP 431. It is a mempool policy change, not a consensus change: blocks containing transactions that violate TRUC rules are still valid. Nodes enforce these rules when deciding which transactions to accept into their mempools and relay to peers.

How It Works

The Transaction Pinning Problem

Transaction pinning exploits the rules governing transaction replacement and descendant limits in Bitcoin's mempool. Two main attack vectors exist:

• BIP 125 Rule 3 pinning: RBF requires a replacement transaction to pay a higher absolute fee than the original plus all of its descendants combined. An attacker attaches a large, low-feerate child to a shared transaction, forcing any replacement to cover the cost of displacing that oversized child. This can make replacement economically infeasible.
• Package limit pinning: standard policy allows up to 25 descendants and 101,000 vB of total descendant size. An attacker fills these limits with their own low-feerate children, completely blocking the victim's ability to use child-pays-for-parent (CPFP).

Both attacks are particularly dangerous for Lightning force-close transactions, where a commitment transaction must confirm within a timelock window or the counterparty can claim funds. For a deeper look at these dynamics, see the research article on v3 transactions and package relay for Lightning.

The Six TRUC Rules

When a transaction sets nVersion=3, nodes enforce six additional mempool policy rules:

1. Implicit replaceability: all TRUC transactions signal replaceability automatically, regardless of BIP 125 signaling. There is no way to opt out of RBF for a v3 transaction.
2. Homogeneous ancestry: any unconfirmed ancestor of a TRUC transaction must also be TRUC. Any descendant of an unconfirmed TRUC transaction must also be TRUC. Once confirmed, transactions of either version can be spent freely.
3. Topology limits: a TRUC transaction can have at most 1 unconfirmed ancestor and at most 1 unconfirmed descendant. CPFP Carve Out does not apply.
4. Parent size limit: a TRUC parent transaction cannot exceed 10,000 vB (sigop-adjusted virtual size).
5. Child size limit: a TRUC child with an unconfirmed TRUC parent cannot exceed 1,000 vB (sigop-adjusted virtual size).
6. Zero-fee parent allowed: a TRUC parent may pay 0 fees if submitted as part of a package where the child's feerate brings the package above mempool minimum requirements.

Why These Rules Prevent Pinning

The combination of a 1-child limit and a 1,000 vB child size cap means that the maximum additional fee required to evict an attacker's child is roughly 100x smaller than under standard rules (1,000 vB versus up to 100,000 vB). When a new, higher-feerate child is submitted for a TRUC parent that already has a child, the existing child is evicted and replaced: a mechanism called sibling eviction.

This guarantees that either party in a two-party contract can always fee-bump their shared transaction at a reasonable cost, regardless of what the counterparty does.

Comparison to Standard Policy

Creating a TRUC Transaction

Opting into TRUC requires setting the nVersion field to 3 in the raw transaction. Previous standard versions were 1 (original) and 2 (introduced with BIP 68 for relative timelocks via OP_CHECKSEQUENCEVERIFY). Version 3 had no prior standard usage, making it safe to repurpose for TRUC signaling.

# Create a TRUC transaction using Bitcoin Core RPC
bitcoin-cli createrawtransaction '[{"txid":"...","vout":0}]' '[{"address":0.001}]'

# The returned hex starts with version bytes (little-endian):
# 02000000... (version 2, standard)
# 03000000... (version 3, TRUC)

# To set version 3, use the 'version' parameter:
bitcoin-cli createrawtransaction \
  '[{"txid":"...","vout":0}]' \
  '[{"address":0.001}]' \
  0 3

Relationship to Package Relay and Ephemeral Anchors

TRUC is one piece of a larger set of mempool improvements that work together. Understanding the full picture requires three related concepts:

Package Relay

Bitcoin Core 28.0 introduced 1-parent-1-child (1p1c) package relay, which allows a low-feerate parent transaction to enter the mempool when bundled with a fee-paying child. This is essential for TRUC because rule 6 allows zero-fee parents: such transactions can only propagate through the network as a package with their child.

Pay-to-Anchor (P2A)

Defined in BIP 433, Pay-to-Anchor is a new output type with the script OP_1 <0x4e73>. It is a keyless output that anyone can spend without providing a signature or witness data. This minimizes the onchain footprint of anchor outputs and replaces the per-party anchors used in current Lightning channels with a single, smaller output.

Ephemeral Anchors

The term ephemeral anchor describes the combination of TRUC + P2A + ephemeral dust policy. A zero-fee TRUC parent includes a P2A dust output that gets immediately spent by a fee-paying child. The anchor output is created and consumed in the same package, so it never materializes in the UTXO set. Bitcoin Core 29.0 (April 2025) added the ephemeral dust policy that allows a single dust output in a zero-fee TRUC transaction, provided it is spent in the same package.

Why It Matters

Lightning Network Force-Closes

Current Lightning commitment transactions are pre-signed with a feerate chosen at channel-open time or updated via update_fee negotiation. If mempool feerates spike, the pre-signed feerate may be too low, and the commitment transaction gets stuck. The update_fee mechanism is also a source of disagreements that can themselves trigger force-closes.

With TRUC, commitment transactions can be pre-signed with zero fees and a single P2A anchor output. Either channel party can then CPFP by spending the anchor with a fee-paying child, setting the effective feerate dynamically at broadcast time. The 1,000 vB child limit prevents the counterparty from pinning the commitment transaction.

The Lightning specification for this approach is defined in BOLTs PR #1228, which introduces zero-fee commitment channels. For more on how Bitcoin fee-bumping strategies work together, see the fee-bumping guide.

Other Layer 2 Protocols

Any protocol that relies on pre-signed transactions with counterparties benefits from TRUC. This includes discreet log contracts, coinswaps, Ark, and other contract protocols where timely confirmation is critical for security.

Use Cases

• Lightning force-close protection: zero-fee commitment transactions with dynamic CPFP fee-bumping, eliminating feerate guessing and reducing pinning risk to near zero.
• HTLC resolution: Lightning HTLC transactions can also use TRUC, ensuring that timeout and success transactions can be fee-bumped reliably during periods of high mempool congestion.
• Two-party contract settlement: any pre-signed transaction shared between counterparties (such as submarine swaps or atomic swaps) can use TRUC to guarantee that either party can broadcast and fee-bump without interference.
• Fee-sensitive broadcasts: TRUC's zero-fee parent rule lets applications defer fee decisions until broadcast time, reducing the risk of overpaying or underpaying fees on pre-signed transactions.

Deployment Timeline

Risks and Considerations

Opt-In Adoption

TRUC is opt-in: only transactions that set nVersion=3 are subject to these rules. Existing software continues to use version 1 or 2 transactions under standard policy. Wallets and Layer 2 implementations must be updated to create v3 transactions and handle the topology constraints.

Size Constraints

The 1,000 vB child limit means the fee-bumping child transaction cannot include many inputs. If a user needs to aggregate UTXOs to pay fees, they may not have enough space within a single TRUC child. Applications should maintain UTXOs of sufficient value for fee-bumping purposes.

Policy, Not Consensus

Because TRUC is enforced at the mempool policy level rather than the consensus level, miners can include transactions that violate TRUC rules in valid blocks. A miner cooperating with an attacker could bypass TRUC protections by including a pinning transaction directly in a block template without relay. In practice, this requires direct miner collaboration, which is costly and difficult to sustain.

Transition Period

During the period when not all nodes have upgraded to Bitcoin Core 28.0 or later, TRUC transactions may not relay through the entire network. Nodes running older versions treat nVersion=3 as non-standard and will not relay these transactions. As network-wide adoption of 28.0+ increases, relay reliability improves. The cluster mempool upgrade in Bitcoin Core 31.0 further cements TRUC as the recommended approach by removing CPFP Carve Out entirely.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.