Sending Bitcoin with SSP
This guide walks you through sending Bitcoin from an SSP wallet end to end. There are five steps, one signing prompt on the device that initiates the send, and one co-signature confirmation on the second device. The whole thing takes under a minute once you know the screens.
It's written for anyone with an SSP wallet about to send their first BTC transaction — and worth re-reading before your hundredth, because the address-checking habits are what keep funds safe.
Before you start
Three prerequisites — none of them optional.
- Both paired devices are powered on and unlocked. SSP's 2-of-2 model needs signatures from both. If one device is dead, charging, or asleep, the send won't complete.
- You have the recipient address from a trusted source. Copy it — don't type it. Manual entry invites typos, and typos go to the wrong wallet permanently. Trusted sources include the recipient's verified channel, an invoice from a service you control, or a freshly-generated address from your own second wallet.
- You've decided on a fee tier. SSP shows you the current network estimate, but the priority you pick is yours. Faster confirmation costs more; cheaper transactions can sit unconfirmed during congestion. More on this in step 3.
Step 1: Open the send screen
On the mobile app, tap the Send button on the home screen. On the browser extension, click Send in the top action bar.
If your SSP wallet holds multiple chains, the next screen asks you to pick the asset. Select Bitcoin from the list. Confirm you are looking at the correct sub-account — SSP supports multiple accounts per chain, and the balance shown at the top of the send screen is the balance available for that specific account, not the wallet total.
If the balance shown is lower than you expect, back out and verify which account you're sending from. Funds in another account are not spendable from this screen.
Step 2: Paste the recipient address
Paste the recipient's Bitcoin address into the address field. Then — before you do anything else — verify the first 6 characters and the last 6 characters against the trusted source you copied from. Read them out loud if you need to. If even one character is off, stop, clear the field, and re-copy from the original source.
This isn't paranoia. It's defence against a well-documented pattern called address poisoning: an attacker watches the blockchain for your transactions, generates a new address whose first and last characters look almost identical to one you've used before, and sends you a dust transaction so it appears in your history. The next time you copy "the same" address from your transaction list, you copy theirs instead. Your send goes to the attacker. There is no recovery.
Always copy from the original trusted source, never from history. Always check the first and last 6 characters.
Step 3: Enter the amount and review the fee
Enter the amount to send. You can type in BTC, sats, or your local fiat — SSP converts in real time using the current rate. The screen also shows the spendable balance and an estimated total including fee, so you can see immediately whether you have enough.
Below the amount, SSP shows three fee tiers:
- Low — cheapest, but the transaction may sit in the mempool for hours during congestion.
- Normal — the default; typically confirms within the next 1–3 blocks (10–30 minutes on average).
- High — pays a premium for inclusion in the very next block. Useful for time-sensitive transfers, exchange deposits with deadlines, or any moment when "definitely confirmed in the next 10 minutes" matters.
Fee estimates update live. If the network is quiet, even the low tier confirms quickly. If it's busy, expect the gap between low and high to widen significantly.
Step 4: Sign on both devices
This is where SSP's 2-of-2 model fires. The transaction needs an independent signature from each of your paired devices before it can be broadcast.
On the initiating device (the one you've been using so far), review the summary one last time — recipient, amount, fee — and tap Confirm. The device signs locally. It does not yet broadcast.
Switch to the second device. Within a few seconds it should display a pending signing request: the same recipient, amount, and fee, alongside an Approve / Reject choice. Verify that what you see matches the initiating device, then tap Approve. The second device signs and the two signatures are combined.
If the second device doesn't show the prompt within ~15 seconds:
- Make sure the SSP app is in the foreground (not just running in the background).
- Check that battery saver / data saver isn't blocking background sync.
- Confirm both devices have internet — Wi-Fi or mobile data; SSP needs a connection on each side to relay the request.
You can safely retry from the initiating device if needed. Until the second signature is in, no funds have moved.
Step 5: Watch the broadcast
Once both signatures are collected, SSP submits the transaction to the Bitcoin network. The send screen flips to a Pending state and shows the transaction id (txid) — tap it to open a block explorer.
Wait for confirmations. Depth required depends on who is receiving:
- Casual transfers, small amounts — 1 confirmation is usually enough.
- Exchange deposits — most exchanges credit after 1–3 confirmations; check the exchange's policy.
- Large transfers — many recipients wait for 6 confirmations (~60 minutes) before treating the funds as final.
You can close the app at this point. The transaction is on the network; SSP doesn't need to stay open for it to confirm.
Sending via a connected dApp
If the send is triggered by a browser-based dApp rather than initiated inside SSP, you're using <span id="walletconnect"></span>WalletConnect — the open protocol that lets external dApps request signatures from your SSP wallet via QR code or deep link.
The flow is the same from step 4 onward: both devices must independently sign before the transaction broadcasts. The dApp itself never sees your keys — it just gets the signed result.
The difference is in steps 2 and 3: the dApp pre-fills the recipient address, amount, and sometimes the fee. Your job changes from entry to observation — verify that the recipient and amount the dApp is asking you to sign match what you intended to authorise in the dApp's interface. If anything looks off, reject the request and start over from the dApp side.
Related reading
- New to SSP? Start with Setting up your first SSP wallet.
- For the security model behind the two-device flow, see What is 2-of-2 multisig?.