What happens to a half-approved transaction
In a 2-of-2 wallet, every send has an in-between moment: you've approved it in SSP Wallet, and it's waiting for SSP Key on your phone. Maybe the phone is in another room, or you change your mind. Here's where that half-approved transaction waits, how long it lasts, what can be done with it, and how it ends.
Where the request waits
When you confirm a send in SSP Wallet, the wallet builds the transaction, adds its own signature and posts the result to the SSP relay as a signing request. The relay stores it under your wallet's identity and passes it to SSP Key over a live connection and as a push notification. If SSP Key connects later, the relay hands over the waiting request as soon as it joins.
The relay keeps one pending request per wallet. A new request from your wallet replaces whatever was waiting there; there's no backlog of half-approved sends.
SSP Wallet shows a waiting dialog with a countdown. After 30 seconds without an answer, it suggests checking that SSP Key is open and online, and offers a QR code (or text to copy) to load the request on the phone by hand.
How long it lasts
A request is valid for 15 minutes. The relay stamps every request with an expiry time 15 minutes after creation, and its database deletes the record automatically once that time has passed. The wallet's countdown mirrors that window; the relay is what enforces it.
After that, the request is gone. SSP Key can't fetch it, and SSP Wallet tells you it expired and to try again. Nothing was broadcast, so there's nothing to undo on the blockchain.
The phone is offline, you reject, or you never answer
The phone is offline. The request waits on the relay. If SSP Key comes back online within the 15 minutes, it picks the request up. If not, the request expires.
You reject on SSP Key. SSP Key sends a rejection back through the relay, and the rejection takes the request's place. SSP Wallet shows "Transaction Rejected" and confirms that the transaction won't reach the blockchain and your funds are fully available.
You never answer. The request expires after 15 minutes, as above.
You close the dialog in SSP Wallet. Closing the dialog doesn't cancel the request. The dialog says so itself: the request stays pending on SSP Key until it expires, and it also shows as a pending send in your activity list.
So there's no separate "cancel" button for a consumer send. A request ends in one of four ways: SSP Key approves it, SSP Key rejects it, it expires, or a newer request from your wallet replaces it. If you've changed your mind, the cleanest option is to reject it on SSP Key.
Can anyone use the half-signed transaction?
No. Your funds sit in a 2-of-2 multisig, and a valid spend needs both signatures. On UTXO chains such as Bitcoin, the address's script itself requires two signatures from two specific keys, and the network rejects a transaction with only one. On EVM chains, the smart account checks one combined signature that can only be produced with both keys. Anyone who sees it, including the relay, holds a transaction no network will accept. What is 2-of-2 multisig explains the mechanics.
Nor does SSP Key sign on autopilot: it decodes the transaction on the device and waits for your approval. What actually stops a transaction covers the other checks along the way.
The half-signed transaction can't move funds, but it isn't secret. It contains the recipient, the amount, your sending address and, on UTXO chains, the coins being spent. The relay decodes it to write the push notification ("a transaction of X to Y"). That's part of what the SSP relay can and cannot see: enough to read what you're sending, but nothing that lets it move your funds.
Coins and nonces while you wait
Nothing is broadcast until SSP Key signs, so nothing changes on-chain while a request waits.
On UTXO chains, the coins chosen for the transaction stay unspent. SSP Wallet doesn't set them aside for a pending consumer send. If you start a second send, it can pick the same coins, and the new request replaces the old one on the relay anyway. SSP Key doesn't trust the coin details in the request. It looks up the coins itself before signing.
On EVM chains, two kinds of nonce are involved. The account nonce, the counter explained in Nonces: why Ethereum transactions wait in line, is read when the transaction is built and only advances when a transaction is included, so a waiting or rejected request doesn't use one up. The other is a one-time signing nonce for the combined signature. SSP Wallet discards it once used, so it never signs a second transaction, even if the first was rejected or expired.
How SSP Enterprise differs
SSP Enterprise vaults use M-of-N proposals, which are built to wait longer: 7 days by default, or anywhere from 1 hour to 30 days by vault policy. The proposal's creator, or an organisation admin or owner, can cancel it, releasing the coins or nonce it reserved. If a proposal can no longer land, for example because its coins were spent elsewhere, it's closed as stale and its signers are told why.
The honest summary
A half-approved SSP transaction is a signing request on the relay with a 15-minute lifetime. It ends when it's approved, rejected, expires or is replaced. Closing the wallet dialog doesn't cancel it, and there's no separate cancel button, so rejecting on SSP Key is the clean way out.
While it waits, it can't move your funds: a 2-of-2 multisig needs both signatures, and SSP Key asks you before adding its own. It does carry readable details such as recipient, amount and address, and the relay can see them.
