Interface tour · version 2.5.3
Sparrow is a tab-based desktop application for on-chain Bitcoin: one window, a wallet open in it, and a row of tabs that each answer a different question about your money. This page walks the interface the way you will actually use it, then gets specific about the two features people search for most: replacing an unconfirmed transaction, and signing a message to prove an address is yours.
Buy bitcoin to move into cold storage
Unofficial
Sparrow holds no coins. It holds a description of which coins your keys can spend, and it knows how to build, inspect and sign transactions that spend them. Whether it is a hot wallet or a cold one is your choice: with a software keystore on an internet-connected computer, the keys are on that computer; with a hardware signer over USB or fully airgapped, the online machine only ever sees public data and unsigned transactions.
The platform story is short. Windows, macOS and Linux, on x86-64 and ARM64, and nothing else. Not browser based by design, which the project justifies on attack-surface grounds. No extension, no mobile app, no web version.
What you get in exchange for that narrowness is depth. Every common script type, genuine multisig, output descriptors you can read, coin control that goes down to the individual UTXO (an unspent output, the indivisible chunk a bitcoin balance is really made of), and a transaction editor that shows you the bytes you are about to pay for.
On logos and screenshots
We do not reproduce the Sparrow logo or screenshots of the application here. The diagrams on this site are our own recreations of documented behaviour; for official imagery and the real interface, see the project's own features page.
The tour
The transactions view is the wallet's home: every payment in and out, its confirmation count, and the label you gave it. Because Sparrow is a lightweight client it gets this history from an Electrum-protocol server rather than by validating the chain itself, so a fresh wallet populates in seconds. Click any entry and you drop into the transaction editor, which doubles as a blockchain explorer: you can walk backwards into the inputs of a transaction that is not even yours.
The receive view hands you the next unused address and lets you attach a label before anyone pays you. Addresses are derived from your keys in sequence, and Sparrow watches a window of them called the gap limit, 20 by default. That number matters when restoring: if you skipped far ahead and generated addresses beyond the window, a restored wallet can look empty until you raise the limit.
Two newer options avoid address reuse entirely. Silent payments (BIP352) give you a single reusable address that does not link its payers on-chain; sending to one arrived in 2.3.0 and receiving wallets in 2.5.0. PayNym payment codes (BIP47) do something similar between two people who have exchanged codes, at the cost of a one-off 546-satoshi notification transaction per contact. Pay-to-DNS support (BIP353) lets you send to a human-readable name resolved over DNS rather than to a pasted string.
The UTXO view lists your unspent outputs individually, with labels and amounts, and lets you freeze or select specific ones before building a transaction. Left to itself, Sparrow picks inputs with Branch and Bound and Knapsack algorithms; override it and you decide. This is the mechanical basis of every privacy practice on this site, because which coins you combine in one transaction is what tells an observer that they belong to the same person. The privacy toolkit covers the policies to apply on top of the tool.
The transaction editor is the feature the software is known for. Inputs and outputs appear as an editable diagram, with the change output identified, the virtual size in bytes, the fee and the resulting fee rate, and whether replace-by-fee is signalled. Fee estimation charts sit next to it so a rate is a decision rather than a guess. A wrong output or an accidentally enormous fee is visible here, while the transaction is still unsigned and completely harmless.
Every unsigned transaction is a PSBT, the standard partially signed format, and Sparrow treats PSBTs as a first-class citizen rather than an export option. That is what makes collaboration possible: one machine builds, another signs, a third broadcasts.
Keystores are configured per wallet. A software keystore keeps an encrypted key in the wallet file. A connected hardware wallet signs over USB. An airgapped device never touches the machine at all: the unsigned PSBT crosses as a QR sequence, using UR fountain codes for transactions too large for one code, or on an SD card, and the signed result comes back the same way. A watch-only wallet built from an xpub (the extended public key that generates all your addresses without being able to spend from them) lets you monitor funds on a machine that holds no secrets at all.
Wallet-level choices live outside the tabs: which server you connect to, whether Tor is used, which network you are on, and the wallet's own encryption. Testnet is reached by restarting into it from the Tools menu, which keeps test coins and real coins in separate worlds rather than one dangerous list.
Every transaction, input and output can be labelled, and labels export and import as a file. Two years later, labels are the difference between a comprehensible history and a pile of anonymous amounts you are afraid to spend.
Source: sparrowwallet.com — features
The question with the most wrong answers online
You paid too little in fees, or you paid the wrong person, and the transaction is sitting unconfirmed. What you can do next depends entirely on one flag and one fact.
If the transaction signalled replace-by-fee, you can build a replacement that spends the same inputs, pays the same recipient the same amount, and offers miners a higher fee. The network relays it, nodes drop the original, and your payment confirms. The recipient's amount does not change; the change output shrinks to fund the extra fee.
The same mechanism, aimed differently: a replacement that spends those inputs but sends the funds to an address you control, at a higher fee. This is the closest thing to cancelling that Bitcoin offers. It is not a cancel button, it is a race, and the original can still win if a miner includes it before your replacement propagates.
Without the flag, replacement is off the table and only acceleration is left. Child-pays-for-parent spends an unconfirmed output of the stuck transaction with a high enough fee that a miner has to include both to collect it. It requires that one of those outputs is yours, usually the change, and it can never redirect the payment.
Sparrow shows you whether replace-by-fee is signalled while you are still building the transaction, in the same editor that shows the fee rate. That is the moment to decide, because the flag cannot be added afterwards.
A confirmed transaction cannot be cancelled, reversed or refunded
Not by Sparrow, not by a miner, not by anyone. Once a transaction is in a block, the coins belong to whoever controls the output you paid. Every "recovery service" that offers to reverse a confirmed Bitcoin transaction is a second theft aimed at someone who has just suffered a first one. The only remedy that exists is asking the recipient to send it back, which is why address verification before signing is worth the ten seconds it costs.
Taproot is offered as a script type when you create a wallet, next to native segwit, nested
segwit and legacy. In day-to-day use the differences are modest: addresses start with
bc1p, single-key spends are slightly cheaper to sign, and all
taproot outputs look alike on-chain regardless of the spending conditions behind them.
The caveat is not Sparrow, it is the rest of your setup. A hardware signer has to
understand taproot to sign for it, and an exchange or service you withdraw from has to be
willing to send to a bc1p address. Confirm both before you commit a balance to
a taproot wallet, and check the
device matrix for your signer.
Signing a message means producing a signature over some text with the private key behind an address. Anyone holding the address, the text and the signature can verify that whoever produced it controls that key. No coins move, no fee is paid, and nothing touches the blockchain.
The original scheme only worked for legacy addresses, which became useless as everyone moved to segwit and taproot. BIP-322 defines a generic signing format that covers modern script types, and Sparrow implements it. The practical uses are narrow but real: proving to a counterparty that a deposit address really is yours, demonstrating control of funds without spending them, or authenticating to a service that accepts a signed message.
Treat the text you sign as seriously as a transaction. A signature proves control to whoever holds it, and there is no reason to sign a blob of data you did not read.
Two columns of capability, each with the reason it exists rather than a checkmark.
Source: sparrowwallet.com — features
The same design that makes Sparrow trustworthy makes it unwelcoming, and pretending otherwise wastes your time.
It is dense. A first-time user opens a window full of tabs, a script type dropdown and a keystore panel before a single coin has moved, and there is no guided path through any of it. Wallets aimed at newcomers make those decisions silently; Sparrow asks.
It exposes concepts other wallets hide. Gap limits, output descriptors, derivation paths, script types, UTXOs, PSBTs. Every one of them is a real thing you eventually benefit from understanding, and every one of them is also a wall on day one.
And there is no hand-holding when you get something wrong. Send to the wrong address and the software will have shown you the address, the amount and the fee, and then done exactly what you asked. There is no support desk, no reversal, no undo. The transparency is the safety net, and it only works if you read what is on screen.
As an on-chain Bitcoin toolkit for a desktop, this is close to the top of what free software offers. The transaction editor, coin control and airgapped PSBT workflow are genuinely better than the alternatives, and taproot, BIP-322 and silent payments show a project that keeps up with the standards that matter.
It is the wrong choice if you want one app for several chains, if you transact mostly from a phone, or if you want someone to call when something goes wrong. Those are not gaps waiting to be filled; they are decisions.
If the depth appeals, start with a verified copy and a wallet you can restore before you fund it: download and verify, then set up the seed.
One feature to use on day one
Label every incoming transaction as it arrives. It costs five seconds, it survives export and import, and it is the only feature here whose value compounds purely with time.
Yes. Taproot (P2TR) is one of the script types you can choose when creating a wallet, alongside native segwit, nested segwit and legacy. Whether you can sign for a taproot wallet also depends on the keystore: software keystores handle it, and most current hardware signers do too. Check the device compatibility table before you move funds into a taproot wallet held on hardware.
Only while it is unconfirmed, and only if it signalled replace-by-fee. In that case you can broadcast a replacement that spends the same inputs, either paying a higher fee for the original payment or redirecting the money back to an address you own. Once a transaction has a confirmation, nothing in Sparrow or anywhere else can cancel or reverse it.
It lets you produce a signature that proves you control the private key behind an address, without moving any coins. BIP-322 generalises the old legacy-address-only scheme so it works for modern script types too. People use it to prove ownership of a deposit address, to satisfy a proof-of-funds request, or to authenticate to a service that accepts a signed message instead of a password.
Neither. The project deliberately avoids browser technology, describing it as a large attack surface, and ships a tab-based desktop application instead. There is no extension, no WalletConnect and no dApp connector, and no official mobile build either.
It is built for people who want to see what their wallet is doing, and it does not hide the parts other wallets hide. A patient beginner can absolutely run it, particularly with a hardware signer, but expect to learn what a UTXO, a descriptor and a gap limit are rather than being shielded from them. Our full review is blunt about who should pick something simpler.
Yes, in both directions as of the 2.5 series: sending to a silent payment address arrived in 2.3.0 and silent payment receiving wallets (BIP352) landed in 2.5.0. Current release is 2.5.3. Silent payments give you one reusable address that does not create an on-chain link between the people paying it.
No to both, permanently. Sparrow is on-chain Bitcoin only: no Lightning channels, no Ethereum, no tokens, no stablecoins. What is and is not supported covers the reasoning and the alternatives.
Buy on a regulated platform, withdraw to a wallet whose keys you hold, and use the tools on this page to keep the history legible and the fees sane.