Stuck Transactions at Scale: RBF, CPFP and the Pinning Problem

Maciej Lewandowski · July 2026 · Field notes from custody & wallet infrastructure

A stuck transaction on your own wallet is an annoyance. A stuck transaction in a custody system is a client's money in limbo, an SLA burning down, and an operator asking what the runbook says. This is the runbook, or at least the reasoning behind one, for the three chain families where "stuck" means three different things.

Why transactions get stuck at all

The fee market moved. You priced for the mempool at signing time; ten minutes later a burst of activity repriced everything above you.
Mempool eviction. Bitcoin mempools are bounded; when they fill, the lowest-feerate transactions are dropped silently. Your transaction did not fail, it just stopped existing everywhere except your database.
Queue effects. On Ethereum, an account's transactions confirm in nonce order. One underpriced transaction dams the whole river behind it.
Expiry. On Solana a transaction references a recent blockhash and dies after roughly 150 slots. Stuck resolves itself into dead, which is cleaner, but only if your system models it.

Bitcoin: RBF, CPFP, and who controls the remedy

Replace-by-fee rebuilds the same payment with a higher fee. The replacement must generally pay for what it displaces (the BIP-125 rules), and since every signature commits to the transaction, RBF means re-signing. That is fine when the transaction is entirely yours. It stops being fine the moment other parties contributed inputs: their signatures die with the replacement, and your remediation now has a human coordination step in it.

Child-pays-for-parent attacks the problem from the other side: spend an output of the stuck transaction (typically your change) with a generously overpaying child. Miners evaluate the pair as a package, the ancestor feerate rises, both confirm. No re-signing, no counterparties, no permission needed. Which is why the practical rule is:

RBF when the transaction is entirely yours and cheap coordination is possible. CPFP when anyone else signed it, when the signing path is slow or cold, or when you simply need a remedy that depends on nobody. Design wallets so that CPFP is always available: always leave yourself a spendable output.

Pinning is the adversarial version. Package rules cut both ways: a counterparty who owns an output of your transaction can attach a large, low-feerate child, making replacement prohibitively expensive under the "pay for what you displace" rule, and the package unattractive to miners. The transaction is frozen in public view. Protocols that live and die by timely confirmation (Lightning, most visibly) evolved anchor outputs and package-relay improvements specifically to shrink this attack surface. If your flows include transactions co-signed with parties you do not fully trust, pinning belongs in your threat model, and "wait for mempool expiry, around two weeks by default" belongs in your expectations.

Ethereum: it is always the nonce

EVM remediation is mechanically simpler and operationally trickier:

Speed-up: same nonce, same payload, higher fees. Nodes demand a meaningful bump (conventionally at least 10%) to replace the pending transaction.
Cancel: same nonce, zero-value self-transfer, higher fees. You are buying the nonce back.
The queue is the real system. Remediating transaction N is pointless if N-1 is the stuck one, and a nonce gap (say, after a crashed signer burned a nonce that never reached the network) silently freezes an entire account. Monitoring must think in accounts and gaps, not in individual transactions.
EIP-1559 makes one failure mode gentler: set a generous max fee and the transaction rides the base fee down without overpaying, since the base fee is burned and refunds the difference. Underpriced priority tips still strand you in a busy mempool.

Solana: stuck is temporary, dead is forever

Blockhash expiry means Solana rarely has zombie transactions; it has ambiguous ones. The dangerous window is between expiry-as-observed and expiry-as-fact: resubmit a "dead" transaction's intent as a new transaction too eagerly, and if the original squeaked in at the boundary you have paid twice. The discipline is the same as everywhere else, just compressed in time: track the transaction by signature until its blockhash is provably expired, then and only then rebuild with a fresh blockhash under the same idempotency key. For signing flows too slow for a 60-90 second window (cold storage, multi-approval), durable nonces exist precisely to opt out of expiry.

The ops layer: remediation is a policy, not a heroic act

Every remediation above is mechanical. What separates calm systems from noisy ones is that the mechanics are wired to policy instead of adrenaline:

Age alarms per state, per chain. A transaction pending longer than its chain's expected profile triggers evaluation, automatically.
Automatic fee-bumps within bounds. Policy defines the bump curve and the ceiling. Below the ceiling, no human is involved. At the ceiling, a human decides, with context in front of them.
Idempotency keys survive remediation. Replacement, cancel and rebuild all inherit the original intent's key. The client asked to withdraw once; the ledger must agree regardless of how many transactions it took.
REPLACED and EXPIRED are first-class states, so monitoring reports remediation as progress, not as a fresh incident.
Nothing settles on broadcast. The stuck window is exactly why crediting, reporting and client notification key off confirmations, never off submission.

Stuck transactions are not edge cases. They are weather. Systems that treat them as storms stay in firefighting mode forever; systems that treat them as Tuesday build the umbrella into the architecture.