Swapping Crypto from SSP: Buy, Sell, and Swap Explained

Moving between assets is one of the most common things people do in a wallet. From SSP, you have three different ways to do it — buy, sell, and swap — and although they share an interface, they work in very different ways under the hood. Understanding the difference matters because each flavor has its own fees, its own counterparty model, and its own custody implications for your funds.

This guide walks through all three, explains where SSP's in-wallet aggregator fits in, and shows when going directly to a DEX via WalletConnect makes more sense.

What stays the same: the 2-of-2 custody model

Before we talk about flavors, the constant: SSP is a 2-of-2 multisig wallet. Every transaction that leaves your address — whether it's a transfer to an on-ramp provider, a swap call to a DEX router, or a token approval — needs a signature from your extension AND a signature from your SSP Key. No third party, no SSP backend, and no provider integrated into the wallet can move a single satoshi or wei on your behalf without both devices saying yes.

That's the part that does not change when you swap. The provider you route through, the dApp you connect to, the chain you're on — those all vary. The 2-of-2 signing requirement does not.

Flavor 1: Buy (fiat to crypto)

The "buy" flow in SSP is a fiat on-ramp. You hand over US dollars, euros, or another local currency via card, bank transfer, or an equivalent rail, and a third-party provider settles the crypto to your address.

Here is what's actually happening:

• SSP integrates with one or more on-ramp providers. When you start a buy, the wallet hands you off to that provider's flow.
• The provider asks for KYC (identity verification) and payment details. This part has nothing to do with SSP — it's the provider's regulated checkout.
• Regional availability depends on the provider's licenses. Some chains, fiat currencies, and payment methods are available in some countries and not in others.
• When the payment clears, the provider sends crypto to your SSP address. From that moment, the asset is in your 2-of-2 custody — exactly like any other inbound transfer.

Two practical notes. First, the price you pay includes the provider's spread and fees on top of the underlying market rate; this is normal for on-ramps but worth comparing between providers if you have a choice. Second, you never send the provider any keys, seed, or signing power — they only need a destination address.

Flavor 2: Sell (crypto to fiat)

Sell is the mirror image. You send crypto from SSP to a third-party off-ramp provider, and the provider deposits fiat to your bank account.

Mechanically:

• You initiate a sell from SSP and the wallet hands you off to the provider.
• KYC and a withdrawal destination (bank account, card, or equivalent) are collected by the provider.
• You sign a normal send transaction in SSP — extension signature + SSP Key signature — that moves your crypto to the provider's receiving address.
• After the provider receives and confirms the on-chain transfer, fiat is paid out to your withdrawal destination.

The signing step is the same as any other outbound transfer. SSP does not have a special "sell" key path; it's a 2-of-2-signed send addressed to the off-ramp's deposit address, with the provider taking over from there.

Flavor 3: Swap (crypto to crypto)

This is where things get more interesting. There are two architecturally different ways to swap one token for another from SSP, and they have different trade-offs.

Option A: SSP's in-wallet swap aggregator

SSP has an in-wallet buy/sell/swap aggregator that lets you exchange one crypto asset for another without leaving the wallet. Conceptually, the aggregator queries multiple third-party providers and DEX aggregators on your behalf, picks a route, and presents it to you as a single operation.

What you see:

• A "from" and "to" asset, an amount, and a quote that includes the expected output, the price impact, and the total fees.
• A single confirmation step that, behind the scenes, may involve a token approval (if you're swapping an ERC-20) and the actual swap transaction.
• You approve from your extension and confirm on your SSP Key, just like any other transaction.

What you don't see:

• Which specific providers were queried, and which pools or routers the chosen route uses.
• Provider-side spread and routing fees, which are bundled into the quoted output.

This option is convenient. You stay in the SSP interface, you don't have to manage a WalletConnect session, and you get a "one operation" experience. The trade-off is that the price comes from third parties — the aggregator is fetching quotes, not running its own liquidity. Always look at the quoted output, the price impact, and the total fees before confirming, and start with a small test amount when you try a new pair.

Option B: Going directly to a DEX via WalletConnect

The other option is to connect SSP to a DEX dApp — Uniswap is the canonical example — using WalletConnect. The dApp becomes the swap UI; SSP remains the signer.

This approach exposes the full DEX surface:

• The specific pools and routes the DEX uses.
• Advanced features like limit orders, custom slippage tolerance, fee tiers, and direct interaction with newer or smaller liquidity pools.
• Whatever incentive programs, governance tokens, or analytics that DEX exposes.

It also exposes you to the full DEX surface, which means more things to set correctly and more risk vectors to be aware of. You will manage token approvals explicitly, you will be more directly exposed to slippage and price impact, and on public mempools you will need to think about MEV like frontrunning and sandwich attacks.

The custody picture does not change. The DEX router is just a smart contract; the swap is a transaction your 2-of-2 signs. The DEX never holds your funds — it executes the swap atomically on-chain. If anything goes wrong before the trade settles, the transaction reverts and you keep your input asset (minus gas).

A simple decision frame

The two options aren't a hierarchy — they serve different needs. A rough heuristic:

• Common pairs, simple swap, want one operation: the in-wallet aggregator is usually the better experience.
• Long-tail tokens, advanced order types, specific pool, or DEX-native features: go directly via WalletConnect.
• Large size or sensitive timing: look at both quotes and consider splitting across routes; pay attention to MEV protection options on the dApp side.

There is no shame in using both. Many SSP users do common stablecoin swaps in-wallet and switch to a DEX dApp when they need something specific.

What to actually check before you confirm

For every flavor — buy, sell, swap, in-wallet or via a dApp — these are the same questions:

• What is the quoted output? The number of units of the destination asset you'll actually receive after fees and price impact.
• What are the total costs? Spread, provider fees, DEX fees, and gas. For an ERC-20 on Ethereum, gas can dominate small swaps; on Polygon, Base, BNB Smart Chain, or Avalanche, gas is much lower but still non-zero.
• Is this the in-wallet route or an external dApp? The signature flow is the same, but the counterparty model is different. Knowing which one you're using changes what you should worry about (fee transparency vs approvals and slippage).
• Have I tested with a small amount? For any new pair, provider, or dApp, start small. The few dollars of gas you spend on a test transfer is cheap insurance against a routing or approval surprise.

The constant

Whichever path you take — buy, sell, in-wallet swap, or DEX dApp swap — the custody story is the same. Your two devices sign every send. The asset is in your 2-of-2 multisig before the swap and in your 2-of-2 multisig after. The swap is just a transfer in the middle, and SSP makes that transfer the way it makes every other one: with both signatures, every time.

For deeper background on the underlying mechanics, see Ethereum.org's DeFi overview and the Uniswap documentation.