In neun Tagen wuchs SSP Wallet von einer einzigen EVM-Kette auf vier. v1.18.0 brachte Polygon am 25.03.2025; v1.19.0 folgte am 01.04.2025 mit Binance Smart Chain und Avalanche C-Chain. Die Anzahl der Ketten ist der Aufhänger, aber die eigentliche Geschichte liegt darunter: SSP gibt jeder EVM-Kette eine eigene Adresse, indem es BIP49 mit strenger SLIP44-Ableitung folgt. Eine bewusste, sicherheitsorientierte Entscheidung — und deswegen lautet die Schlagzeile nicht „drei neue Netze", sondern „drei neue Netze, drei neue Adressräume".
Polygon kommt (v1.18.0, 25. März)
v1.18.0 brachte Polygon zu SSP — Mainnet plus das Amoy-Testnet. POL wird nativ unterstützt, ebenso vordefinierte Tokens und beliebige benutzerdefinierte ERC-20, die ein Nutzer importieren möchte. Polygon verhält sich jetzt wie Ethereum seit dem ERC-4337-Launch: derselbe 2-aus-2-Multisig-Flow, dieselbe SSP-Wallet/SSP-Key-Choreografie, derselbe Smart-Wallet mit Account Abstraction, nur auf einer schnelleren und günstigeren L2.
Die Neuheit ist nicht, dass Polygon in SSP ist — sondern dass deine Polygon-Adresse in SSP nicht deine Ethereum-Adresse in SSP ist. Gleiche Seed, gleiches Multisig. Anderer SLIP44-Coin-Type, anderer Ableitungspfad, andere Adresse. Wir kommen gleich darauf zurück.
Dann BSC und Avalanche (v1.19.0, 1. April)
Eine Woche später fügte v1.19.0 Binance Smart Chain und Avalanche C-Chain hinzu. Beide kamen in derselben Form wie Polygon: native Münze (BNB auf BSC, AVAX auf Avalanche), die Standard-Liste vordefinierter Tokens von SSP, und Custom-Token-Importe für alles andere auf diesen Ketten.
Nach zwei Releases unterstützt SSP Ethereum, Polygon, BSC und Avalanche — vier EVM-Netze, vier eigene Adressen. Deine BNB-Adresse ist nicht deine AVAX-Adresse; dein AVAX ist nicht dein ETH; nichts kollidiert. Kein Zufall — das ist der Punkt.
Warum striktes SLIP44 zählt
Die meisten EVM-Wallets tun eine Sache: Sie wählen einen einzigen Ableitungspfad unter dem SLIP44-Coin-Type 60 (Ethereum) und verwenden die resultierende Adresse auf jeder EVM-kompatiblen Kette wieder. ETH auf Ethereum und BNB auf BSC an „dieselbe Adresse" senden — denn auf Kettenebene ist die Adresse byte-identisch. Bequem. Aber auch ein stillschweigender Kompromiss.
BIP44 definierte die hierarchische Struktur: m/purpose'/coin_type'/account'/change/index. SLIP44 definierte das Coin-Type-Register: Bitcoin ist 0, Ethereum ist 60, Polygon ist 966, BSC ist 9006, Avalanche ist 9000. Unterschiedliche Coin-Types ergeben unterschiedliche Ableitungspfade, also unterschiedliche Schlüssel, also unterschiedliche Adressen — obwohl Kurve, Signatur und Byte-Format der Adresse identisch sind.
SSP folgt BIP49 mit striktem SLIP44. Das Wallet respektiert den Coin-Type jeder unterstützten Kette. Polygon leitet unter 966 ab. BSC unter 9006. Avalanche unter 9000. Ergebnis: Jede Kette bekommt eigenes Schlüsselmaterial, eine eigene Adresse, eine eigene Historie pro Kette.
Warum den Aufwand, wenn das Wiederverwenden einer Adresse einfacher wäre?
- Verwechslungen zwischen Ketten kosten Geld. Wenn deine „EVM-Adresse" auf jeder Kette gleich ist, ist es sehr leicht, das falsche Asset in die falsche Umgebung zu schicken — USDC.e auf Polygon an einen Ethereum-erwartenden Empfänger, ein „ich bridge das später" das schiefgeht. Eigene Adressen machen die Kette zum Teil des mentalen Modells, nicht zum versteckten Footgun.
- Privatsphäre und On-Chain-Buchführung. Eine einzige geteilte Adresse erlaubt einem öffentlichen Beobachter, dein Verhalten über jede EVM-Kette zu korrelieren. Eigene Adressen pro Kette verhindern, dass versehentliche Cross-Chain-Verknüpfung der Default ist.
- Schadensradius bei Schlüsselleck. SSP ist Multisig, ein einzelner kompromittierter Schlüssel leert keine Fonds. Aber das Prinzip gilt: Ein Wallet, das einen Schlüssel auf eine Kette abbildet, begrenzt die Oberfläche jeder Ableitung — dasselbe Hygieneargument, das BIP44 2014 für Bitcoin machte.
- Kompatibilität damit, wie andere Wallets Historie indexieren. Werkzeuge, die SLIP44 respektieren, suchen am richtigen Ort nach deiner Polygon-, BSC- und AVAX-Historie. Die, die es nicht tun, behandeln alles weiter als „Coin-Type 60" und verlieren stillschweigend Daten.
Die Produktkosten sind ein zusätzlicher Schritt im Nutzermodell: „Deine Polygon-Adresse ist nicht deine Ethereum-Adresse". Der Vorteil ist ein Wallet, das nicht stillschweigend eine einzige ETH-artige Identität auf jeder neuen Kette recycelt.
Custom-Token-Importe
Alle drei Netze akzeptieren denselben Custom-Token-Import-Flow, der früher in der Timeline für Ethereum-Tokens eingeführt wurde. Wenn das Netz einen ERC-20 (oder ein BEP-20-Äquivalent) unterstützt und du die Vertragsadresse hast, kannst du ihn auf genau dieser Kette hinzufügen. Vordefinierte Listen decken die offensichtlichen Assets ab — Wrapped-Versionen, Stablecoins, die DeFi-Flaggschiff-Tokens — Custom-Importe decken den Rest.
Tokens sind pro Kette. Ein USDC-Vertrag auf Ethereum und ein USDC-Vertrag auf Polygon sind unterschiedliche On-Chain-Artefakte an unterschiedlichen Adressen. SSP behandelt sie genau so, jede Kette zeigt ihre eigene Tokenliste unter ihrer eigenen SLIP44-abgeleiteten Adresse.
Erforderliche SSP-Key-Version
Eine operative Notiz aus dem v1.18.0-Release: Polygon (und damit auch die in v1.19.0 hinzugefügten Ketten) erfordert SSP Key v1.11.0 oder neuer. Der mobile Signer muss die neuen SLIP44-Coin-Types verstehen, um die richtigen Schlüssel beim Signieren abzuleiten. Wenn du auf einer älteren SSP Key bist, aktualisiere sie, bevor du Polygon-, BSC- oder Avalanche-Konten in SSP Wallet hinzufügst — sonst hat das Wallet keine Gegenseite für die 2-aus-2-Signatur.
Nach v1.18.0 und v1.19.0 ist SSP nicht mehr „Bitcoin-Familie plus Ethereum". Es ist ein Multi-Chain-EVM-Wallet, mit drei neuen Netzen in unter zehn Tagen — und einer Ableitungspolitik, die bedeutet, dass jede neue Kette ihre eigene Adresse bekommt, mit Absicht.