Sending and Receiving Ethereum with SSP

Moving ETH in and out of a self-custody wallet is one of the first things you will do after setting up SSP for Ethereum. It is straightforward once you understand the account model and how SSP's 2-of-2 multisig fits into a normal Ethereum transaction. This guide walks through receiving ETH, sending it, and what actually happens behind the scenes when you sign with two devices.

If you are brand new to ETH inside SSP, start with Ethereum in SSP for the bigger picture, then come back here for the hands-on send-and-receive flow.

A quick recap of the account model

Ethereum does not work like Bitcoin under the hood. On Bitcoin, your wallet juggles many unspent outputs and generates fresh change addresses with every spend. On Ethereum, your account is a single address that simply holds a balance. When you receive ETH, your balance goes up. When you send, it goes down. There are no change addresses and no output selection to think about.

This matters for self-custody in two ways. First, you reuse the same address indefinitely, so there is one address to back up, verify, and share. Second, every transaction has to be ordered, which Ethereum handles with a counter called the nonce — more on that below.

In SSP, this single address is your 2-of-2 multisig account. On EVM chains it is an ERC-4337 smart-contract account, so the two keys still gate every spend even though it looks like a normal address on-chain.

Receiving ETH

Receiving is the safer half, because nothing leaves your wallet. You give the sender your address and wait for the network to confirm.

Your 0x address

Your Ethereum receive address starts with 0x followed by 40 hexadecimal characters. SSP shows it as text and as a scannable code so the sender can copy it exactly. Because Ethereum reuses one address, you do not need a new one for each payment.

Verify the address on both devices

Self-custody puts address verification on you. Malware that swaps a copied address for an attacker's is a real industry-wide risk, so confirm the address you are about to share is genuinely yours. SSP shows the account on both the extension and SSP Key, so glance at the first and last characters on each device and make sure they match. The same habit applies when receiving Bitcoin into SSP — verify on hardware you control, not just on a web page someone sent you.

One address for ETH and ERC-20 tokens

The same 0x address receives both ETH and ERC-20 tokens, because tokens live in contracts that credit your address. You do not need a separate address per token. What you do need is to make sure the sender is using the right network.

Choosing the right network

This is the most common way people lose funds on EVM chains. An address that exists on Ethereum mainnet also exists on Polygon, Base, and other EVM chains, but a balance on one chain is not a balance on another. If someone sends ETH on the wrong network, it does not arrive on the one you are watching. Before sharing your address, agree on the exact network with the sender and confirm SSP is set to that same chain. Article 3 covers using SSP on Polygon, Base, and other EVM chains in detail.

Sending ETH: the 2-of-2 co-sign flow

Sending is where SSP's multisig design shows up. A single-key wallet signs once and broadcasts. SSP requires both of your keys, so the flow has one extra approval step — and that step is the whole point of the security model.

Here is the shape of a send, kept general because exact labels can change:

1. In the SSP Wallet extension, choose to send, enter the recipient address and amount, and review the fee.
2. The extension builds the transaction and applies the first signature with key 1.
3. SSP Key on your phone receives a push notification. You review the same details there and co-sign with key 2.
4. With both signatures combined, the transaction is broadcast to the network.

Because neither device alone can move funds, an attacker who compromises only your browser still cannot send. They would also need your phone to approve. On EVM chains SSP combines the two signatures into one using Schnorr aggregation, so what lands on-chain is a single account-abstraction operation rather than two separate signatures. The deeper mechanics are covered in EVM multisig the account abstraction way.

The co-sign habit is identical in spirit to sending Bitcoin with SSP; only the underlying transaction format differs.

The transaction lifecycle

It helps to picture a send as a short pipeline:

• Build — the extension assembles the transaction: recipient, amount, gas settings, and the next nonce.
• Sign — key 1 signs in the extension.
• Co-sign — key 2 signs on SSP Key after you approve the push.
• Submitted / pending — the combined transaction is broadcast and sits in the mempool waiting to be included in a block.
• Confirmed — a validator includes it in a block. Each subsequent block adds confirmations and makes it harder to reverse.

A transaction is only final once it is confirmed on-chain. Until then it is pending and can, in some cases, be replaced. You can watch any transaction's progress on a public block explorer such as Etherscan by pasting in the transaction hash.

Understanding the nonce

The nonce is a per-account counter that orders your transactions. Your first transaction uses nonce 0, the next uses 1, and so on. The network processes them strictly in order.

This has a practical consequence. If one transaction is stuck pending — usually because its gas price was too low for current conditions — every later transaction is blocked behind it, because the network will not skip ahead to a higher nonce. The fix is to replace the stuck transaction: resubmit one with the same nonce but a higher fee, which lets validators pick the new version. Wallets often present this as a "speed up" or "replace" action. SSP still requires the 2-of-2 co-sign for a replacement, because it is a new transaction.

You rarely touch the nonce by hand — SSP fills it in — but knowing it exists explains why a pending transaction can hold up the ones behind it.

Gas, at a high level

Every Ethereum transaction costs gas, paid in ETH. This is true even when you move an ERC-20 token: the token rides on an Ethereum transaction, and that transaction needs ETH for the computation. The practical rule is to keep a small ETH balance so you can cover gas, otherwise a send can fail for lack of gas even when your token balance is fine.

Gas pricing under EIP-1559 splits into a base fee set by the network and a priority tip you add to get included faster. We keep it brief here; for the full picture — base fee, tips, why fees spike, and how to choose them in self-custody — read gas fees on Ethereum, explained for self-custody users.

ETH versus ERC-20 tokens

ETH is the native asset of Ethereum and is what pays for gas. ERC-20 tokens are separate assets defined by smart contracts that track balances against your address. Sending a token is technically a contract interaction rather than a plain value transfer, but in SSP it follows the same build, sign, co-sign, broadcast flow.

Some token actions require a one-time approval before another contract can move tokens on your behalf — common in swaps and DeFi. Approvals are their own topic and out of scope here; just know that a prompt asking to approve spending is a normal part of token interactions, and the same 2-of-2 co-sign protects it.

Practical cautions before you send

• Right network. Confirm the chain matches what the recipient expects. ETH on Base is not ETH on Ethereum mainnet.
• Address format. Ethereum addresses are 0x plus 40 hex characters. Paste, never retype, and verify the start and end on both devices.
• ENS names. Some wallets let you send to a human-readable name like name.eth instead of a raw address. Treat it like any address: confirm it resolves to the recipient you expect before approving.
• Keep ETH for gas. A token-only balance cannot pay its own gas. Hold a little ETH.

For the protocol-level details of how Ethereum transactions are structured, the official Ethereum transactions documentation is a solid reference.

Wrapping up

Receiving ETH in SSP means sharing your verified 0x address on the correct network. Sending adds one deliberate step — the SSP Key co-sign — that turns a single point of failure into two. Keep a little ETH on hand for gas, watch the nonce when a transaction stalls, and confirm the network every time, and day-to-day ETH movement in SSP becomes routine. From here, the gas fees article is the natural next read.