Transaction Sponsorship

What Is Transaction Sponsorship?

Transaction sponsorship is a proposed consensus change to Bitcoin that introduces a new way to increase the effective fee of any unconfirmed transaction. Under this proposal, a third party (the "sponsor") creates a small transaction whose validity depends on the inclusion of a specific target transaction in the same block. If a miner wants to collect the sponsor's fee, they must also include the sponsored transaction, effectively boosting its priority.

The concept was first introduced by Jeremy Rubin in September 2020 on the bitcoin-dev mailing list under the title "Non-Destructive TXID Dependencies for Fee Sponsoring." The proposal was designed as a soft fork: a backwards-compatible consensus rule change that would add a new type of transaction dependency to Bitcoin.

Unlike Replace-by-Fee (RBF), which requires the sender to replace their own transaction with a higher-fee version, and Child-Pays-for-Parent (CPFP), which requires spending an output of the stuck transaction, sponsorship allows completely unrelated parties to pay for a transaction's confirmation. This is conceptually similar to gas sponsorship on account-based blockchains, but adapted for Bitcoin's UTXO model.

How It Works

The original proposal introduced the concept of a "sponsor vector": a field in the sponsor transaction's output script that contains the txid of the transaction being sponsored. The consensus rule is straightforward: a transaction containing a sponsor vector is invalid unless the referenced transaction also appears earlier in the same block.

Original Mechanism

In Rubin's initial design, the sponsor transaction includes a special output script that encodes the target txid:

# Sponsor output script structure (original proposal)
# OP_VER <txid_of_sponsored_tx>
#
# The output uses OP_VER (a reserved opcode) followed by the
# 32-byte txid of the transaction being sponsored.
# Total overhead: ~42 virtual bytes per sponsor

Under this design, the sponsor transaction pays a fee like any normal Bitcoin transaction. Miners see that the sponsor is only valid alongside the target transaction, so they include both in the same block to collect both fees.

Improved Efficiency Proposal

A 2024 refinement on the Delving Bitcoin forum proposed a more blockspace-efficient approach. Instead of encoding the target txid in an output script, the sponsor's signature message (the sighash) commits to the sponsored txid. The key improvements:

1. The txid commitment is signed but not explicitly stored in the transaction, saving bytes
2. The sponsor must appear immediately after the sponsored transaction in the block
3. Validators infer the sponsored txid from block ordering rather than reading it from the script

This reduces overhead from roughly 42 virtual bytes in the original proposal to near zero, making sponsorship significantly more economical.

Mempool Policy Rules

The proposal also specifies mempool relay rules to prevent abuse:

• A transaction with a sponsor vector may not have any child spends in the mempool
• A transaction with a sponsor vector may not have any unconfirmed parents
• Each sponsor vector must reference exactly one transaction
• The referenced transaction must already be present in the mempool
• Sponsors are capped at 1,000 bytes to limit griefing potential

Why It Was Proposed

Existing fee-bumping methods have significant limitations, particularly for multi-party contract protocols. Transaction sponsorship was designed to address these gaps.

Limitations of RBF

RBF requires the original sender to create a replacement transaction with a higher fee. This has several problems in contract protocols:

• Only the sender can bump the fee, so recipients or third parties cannot help
• Replacement transactions must pay a higher total fee than the original, not just a higher fee rate
• Pre-signed transactions (common in Lightning and vaults) cannot use RBF because the fee was fixed at signing time
• RBF is vulnerable to pinning attacks where a counterparty broadcasts a bloated low-fee version that is expensive to replace

Limitations of CPFP

CPFP requires spending an output of the stuck transaction. This introduces its own problems:

• Every transaction that might need fee bumping must include an extra output (an anchor output) specifically for CPFP, wasting block space in the common case
• Only parties who can spend an output of the transaction can use CPFP
• CPFP packages are also vulnerable to pinning: a counterparty can attach a large, low-fee child transaction that blocks legitimate fee bumps
• Mempool policies limit descendant chain lengths, restricting how many times CPFP can be applied

What Sponsorship Solves

Transaction sponsorship decouples fee payment from the transaction itself. Any observer can boost any transaction's fee without needing to spend its outputs, replace it, or even know who created it. This makes it particularly useful for:

• Pre-signed transactions where the fee rate cannot be adjusted after signing
• Multi-party protocols where no single participant should bear the fee-bumping cost alone
• Vault architectures with precomputed transaction trees that cannot include CPFP anchors efficiently

Use Cases

Protocol-Sponsored User Transactions

A service or protocol operator could pay for users' transaction confirmations by sponsoring them. For example, a wallet provider could monitor its users' outgoing transactions and sponsor any that become stuck during fee spikes, improving user experience without requiring the user to take any action.

Lightning Network Fee Management

Lightning channel closes require on-chain transactions with fees that were agreed upon when the commitment transaction was signed. If fees have risen since then, the commitment transaction may not confirm. With sponsorship, either channel party (or the LSP) could sponsor the commitment transaction to ensure timely confirmation, which is critical for enforcing timelocked security guarantees.

Batch Fee Bumping

Exchanges and payment processors that broadcast many transactions could create a single sponsor transaction referencing multiple stuck transactions instead of bumping each one individually. While the original proposal limited sponsors to one target, extensions have been discussed that would allow batch sponsorship, making it more efficient than issuing separate RBF replacements for each transaction.

Vault Recovery

Bitcoin vault designs like those proposed in OP_VAULT (BIP 345) use precomputed transaction trees for recovery paths. These transactions have fees fixed at creation time. Sponsorship would allow vault operators to bump fees on recovery transactions during high-fee environments without needing to rebuild the entire vault structure.

Comparison with Existing Methods

Risks and Considerations

Requires a Soft Fork

Transaction sponsorship requires a consensus-level change to Bitcoin. Soft forks are significant protocol upgrades that require broad community consensus, miner signaling, and extensive review. As of 2026, the proposal remains a discussion-stage concept and has not been assigned a formal BIP number or included in any activation timeline.

Pinning Is Not Fully Solved

While sponsorship reduces pinning surface compared to RBF and CPFP, it does not eliminate it entirely. A malicious counterparty could flood the mempool with low-fee sponsor transactions for the same target, making it expensive for an honest sponsor to outbid them. Mempool policy rules (such as limiting sponsors per transaction) can mitigate this, but the interaction between sponsorship relay rules and existing mempool policy is complex.

Block Space Overhead

Each sponsor transaction consumes additional block space beyond the original transaction. Even with the improved efficiency proposal that reduces overhead to near zero virtual bytes for the reference itself, the sponsor transaction still requires inputs, outputs, and a signature. In aggregate, heavy sponsorship use could reduce the effective transaction throughput of the network.

Alternatives Under Active Development

Several alternative approaches to fee bumping are being developed that do not require a consensus change. These include ephemeral anchors (zero-value anyone-can-spend outputs that enable lightweight CPFP), v3 transactions with restricted topology to prevent pinning, and package relay improvements that allow miners to evaluate parent-child transaction packages as a unit. These policy-only changes may address many of the same pain points without the coordination cost of a soft fork. For a deeper exploration of these fee-bumping techniques, see the research article on Bitcoin fee bumping with RBF and CPFP.

Miner Incentive Alignment

Transaction sponsorship relies on miners rationally including both the sponsor and the sponsored transaction to maximize revenue. While this aligns with standard mining incentives, it adds complexity to block template construction algorithms. Miners must evaluate interdependent transaction sets rather than individual transactions, which could increase computational overhead during block building.

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.