Diagnose the stuck transaction
Paste a txid. The desk reads it with GET-only Blockbook calls and
reports confirmations, fee paid, computed vBytes, effective feerate, and whether any input
signals BIP-125 replaceability (any nSequence ≤ 0xfffffffd — the rule straight out of
pearld's node/mempool/mempool.go, MaxRBFSequence). Nothing here moves coins.
Offline: paste a Blockbook /api/v2/tx JSON instead (air-gapped path)
Child-pays-for-parent
You received a low-fee payment and control one of its outputs. Spend that output in a child transaction paying a fat fee: miners are incentivized to confirm parent + child as a package. You pick the output, enter its key, set the target package feerate — the desk does the exact math, signs locally, re-verifies every signature, and asks twice before broadcasting.
Replace-by-fee
The stuck transaction signaled BIP-125 (diagnosis says so) and you hold the keys to its inputs. Build a replacement spending the same inputs, keeping the same outputs, with the fee bumped by trimming one output you choose. pearld enforces three rules and the desk checks all three before signing: the new feerate must strictly beat the old one, the absolute fee must exceed old fee + min-relay fee, and no output may drop below dust.
Track confirmation
Poll Blockbook for a txid's confirmation count. Loud when the backend is unreachable; stops itself at 1+ confirmations.
Package-feerate verifier
Standalone check: paste a parent txid (and optional child txid), state a claimed package
feerate, and the desk recomputes (parentFee + childFee) / (parentVSize + childVSize) from
Blockbook and rules PROVEN or NOT PROVEN — with the full derivation
on screen so anyone can hand-check it.