In nine days, SSP Wallet went from a single EVM chain to four. v1.18.0 added Polygon on 2025-03-25; v1.19.0 followed on 2025-04-01 with Binance Smart Chain and Avalanche C‑Chain. The chain count is the news hook, but the framing story is the one underneath: SSP gives every EVM chain a distinct address by following BIP49 with strict SLIP44 derivation. That's a deliberate, security‑first choice — and it's why the headline of this release isn't "three new networks" but "three new networks, three new address spaces."
Polygon arrives (v1.18.0, March 25)
v1.18.0 brought Polygon to SSP — mainnet plus the Amoy testnet. POL is supported natively, alongside predefined tokens and any custom ERC‑20 a user wants to import. Polygon now behaves the same way Ethereum has since the ERC‑4337 launch: same 2‑of‑2 multisig flow, same SSP Wallet/SSP Key signing dance, same account‑abstraction smart wallet, just on a faster and cheaper L2.
The novelty isn't that Polygon is on SSP — it's that Polygon's SSP address is not your Ethereum SSP address. Same seed, same multisig setup. Different SLIP44 coin type, different derivation path, different address. We'll come back to why.
Then BSC and Avalanche (v1.19.0, April 1)
A week later, v1.19.0 added Binance Smart Chain and Avalanche C‑Chain. Both arrived in the same shape Polygon did: native coin (BNB on BSC, AVAX on Avalanche), the standard SSP predefined token list, and custom token imports for anything else on those chains.
After two releases SSP supports Ethereum, Polygon, BSC and Avalanche — four EVM networks, four distinct addresses. Your BNB address isn't your AVAX address; your AVAX address isn't your ETH address; none of them collide. That's not an accident — it's the point.
Why strict SLIP44 matters
Most EVM wallets do one thing: they pick a single derivation path under SLIP44 coin type 60 (Ethereum) and reuse the resulting address on every EVM‑compatible chain. Send ETH on Ethereum and BNB on BSC to "the same address" — because, at the chain level, the address really is identical bytes. That's convenient. It's also a quiet trade‑off.
BIP44 defined the hierarchical structure: m/purpose'/coin_type'/account'/change/index. SLIP44 defined the coin‑type registry: Bitcoin is 0, Ethereum is 60, Polygon is 966, BSC is 9006, Avalanche is 9000. Different coin types produce different derivation paths, which produce different keys, which produce different addresses — even though under the hood the curve, the signing, and the byte‑level address format are identical.
SSP follows BIP49 with strict SLIP44. The wallet honors the coin type for every chain it supports. Polygon derives under 966. BSC under 9006. Avalanche under 9000. The result is that every chain gets its own key material, its own address, its own per‑chain history.
Why bother, when reusing one address would be easier?
- Cross‑chain confusion costs money. If your "EVM address" is the same on every chain, it is very easy to send the wrong asset to the wrong execution environment — USDC.e on Polygon sent to an Ethereum‑expecting recipient, an "I'll just bridge it from there" mistake. Distinct addresses make the chain part of the user's mental model, not a hidden footgun.
- Privacy and on‑chain accounting. A single shared address means a public observer can correlate your behavior across every EVM chain you touch. Distinct per‑chain addresses stop accidental cross‑chain linkability from being the default.
- Blast radius if a key is exposed. SSP is a multisig wallet, so a single‑key compromise doesn't drain funds. But the principle holds: a wallet that maps one key to one chain limits the surface that any single derivation participates in — the same hygiene argument BIP44 made for Bitcoin in 2014.
- Compatibility with how other wallets index history. Tools that respect SLIP44 look in the right place for your Polygon, BSC, AVAX history. Tools that don't keep treating everything as "coin type 60" and quietly miss data.
The product cost is one extra step in the user model: "your Polygon address is not your Ethereum address." The benefit is a wallet that doesn't quietly recycle one ETH‑style identity across every new chain it adopts.
Custom token imports
All three networks accept the same custom‑token import flow introduced for Ethereum tokens earlier in the timeline. If the network supports an ERC‑20 (or BEP‑20 equivalent), and you have the contract address, you can add it on that specific chain. Predefined lists cover the obvious assets — wrapped versions, stablecoins, flagship DeFi tokens — and custom imports cover everything else.
Tokens are per‑chain. A USDC contract on Ethereum and a USDC contract on Polygon are distinct on‑chain artifacts at distinct addresses. SSP treats them as such, with each chain showing its own token list under its own SLIP44‑derived address.
Required SSP Key version
One housekeeping note carried over from the v1.18.0 release: Polygon (and by extension the chains added in v1.19.0) require SSP Key v1.11.0 or newer. The mobile signer needs to understand the new SLIP44 coin types in order to derive the right keys at signing time. If you're on an older SSP Key, update it before adding Polygon, BSC or Avalanche accounts in SSP Wallet — otherwise the wallet won't have a counterpart to complete the 2‑of‑2 signature.
After v1.18.0 and v1.19.0, SSP is no longer "Bitcoin family plus Ethereum." It's a multi‑chain EVM wallet, with three new networks settled in under ten days — and a derivation policy that means each new chain comes with its own address, on purpose.