Ich habe mir den Leitfaden zur Mainnet-Migration für @Dusk erneut angesehen und dabei einen leicht zu übersehenden Detailpunkt entdeckt: Wenn man im Wallet auf „Approve“ tippt, heißt das noch nicht, dass $DUSK bereits ins Dusk-Mainnet migriert wurde. Erst die nachfolgende „Execute“-Transaktion löst die Migration wirklich aus. Unterbrechungen zwischen den beiden Schritten können dazu führen, dass Nutzer fälschlich glauben, ihre Assets seien „eingefroren“.
Der offizielle Ablauf ist: ERC-20-Token auf Ethereum oder BEP-20 DUSK auf BNB Chain werden in einen Migrationsvertrag gesperrt, und anschließend werden den entsprechenden Dusk-Mainnet-Konten die entsprechenden nativen Coins ausgezahlt. Nutzer müssen ein selbstverwaltetes EVM-Wallet, ein Dusk-Konto und ETH oder BNB zur Zahlung der Gebühren auf der Quellkette bereithalten. Nach der Bestätigung der Transaktion muss man in der Regel außerdem noch warten, bis sie verarbeitet wurde. Konten von Börsen können diese Abfolge normalerweise nicht direkt über WalletConnect durchführen; sie müssen erst ein Wallet nennen, das sie selbst kontrollieren.
Das Mechanismus selbst ist nicht schwer, die eigentlichen Stolperfallen liegen an den Bediengrenzen. Erstens: „Approve“ ist nur eine Freigabe für Kontingente für den Vertrag und überträgt keine Coins automatisch. Zweitens: Tokens auf der Quellkette haben 18 Dezimalstellen, DUSK im Mainnet hat 9 Dezimalstellen. Der Migrationsbetrag wird nach unten auf die kleinste Einheit LUX gerundet; die Nachkommastelle(n) von weniger als 1 LUX verbleiben im ursprünglichen Wallet. Drittens: Wenn die Tokens nicht ankommen, sollte man zuerst prüfen, ob die „Execute“-Transaktion erfolgreich war – statt die Freigabe erneut zu erteilen.
Dieses Design mit einseitigem Sperren und anschließender Auszahlung ist klarer als zu erwarten, dass Nutzer selbst einen Cross-Chain-Pool finden. Dennoch packt es zwei Ketten, zwei Wallets und zwei Bestätigungen in denselben Ablauf. Für alte Nutzer bedeutet das höchstens, einmal mehr hinzusehen; für neue kann es jedoch dazu führen, dass sie „Approve erfolgreich“ mit „Migration abgeschlossen“ verwechseln. Wenn die Sicherheitsmechanismen nicht verständlich genug in der Benutzeroberfläche erklärt werden, wird daraus am Ende trotzdem menschlicher Bedienfehler.
Wenn ich mir die Mainnet-Migration von #dusk anschaue, sehe ich daher nicht nur, ob der Vertrag audited ist, sondern auch, ob das Wallet die aktuellen Schritte, den Hash der Quellkette, den erwarteten Verarbeitungsstatus und die Empfängeradresse gleichzeitig anzeigt. Die offiziellen Dokumente geben einen konkreten Prüfpfad an – das ist ein Pluspunkt. Der nächste Schritt sollte sein, diese Hinweise in jede wichtige Schaltfläche zu integrieren, anstatt darauf zu warten, dass Nutzer nach einem Fehlschlag erst das Help-Center aufschlagen.
Welche Stelle bei der Migration eurer Assets macht euch am meisten Angst: die Freigabe, das falsche Netzwerk auswählen oder ein undurchsichtiger Kontostand nach dem Transfer? Erzähl mal, welche Bedien-Stolperfallen du selbst schon erlebt hast.
$ACE $BTC
Der offizielle Ablauf ist: ERC-20-Token auf Ethereum oder BEP-20 DUSK auf BNB Chain werden in einen Migrationsvertrag gesperrt, und anschließend werden den entsprechenden Dusk-Mainnet-Konten die entsprechenden nativen Coins ausgezahlt. Nutzer müssen ein selbstverwaltetes EVM-Wallet, ein Dusk-Konto und ETH oder BNB zur Zahlung der Gebühren auf der Quellkette bereithalten. Nach der Bestätigung der Transaktion muss man in der Regel außerdem noch warten, bis sie verarbeitet wurde. Konten von Börsen können diese Abfolge normalerweise nicht direkt über WalletConnect durchführen; sie müssen erst ein Wallet nennen, das sie selbst kontrollieren.
Das Mechanismus selbst ist nicht schwer, die eigentlichen Stolperfallen liegen an den Bediengrenzen. Erstens: „Approve“ ist nur eine Freigabe für Kontingente für den Vertrag und überträgt keine Coins automatisch. Zweitens: Tokens auf der Quellkette haben 18 Dezimalstellen, DUSK im Mainnet hat 9 Dezimalstellen. Der Migrationsbetrag wird nach unten auf die kleinste Einheit LUX gerundet; die Nachkommastelle(n) von weniger als 1 LUX verbleiben im ursprünglichen Wallet. Drittens: Wenn die Tokens nicht ankommen, sollte man zuerst prüfen, ob die „Execute“-Transaktion erfolgreich war – statt die Freigabe erneut zu erteilen.
Dieses Design mit einseitigem Sperren und anschließender Auszahlung ist klarer als zu erwarten, dass Nutzer selbst einen Cross-Chain-Pool finden. Dennoch packt es zwei Ketten, zwei Wallets und zwei Bestätigungen in denselben Ablauf. Für alte Nutzer bedeutet das höchstens, einmal mehr hinzusehen; für neue kann es jedoch dazu führen, dass sie „Approve erfolgreich“ mit „Migration abgeschlossen“ verwechseln. Wenn die Sicherheitsmechanismen nicht verständlich genug in der Benutzeroberfläche erklärt werden, wird daraus am Ende trotzdem menschlicher Bedienfehler.
Wenn ich mir die Mainnet-Migration von #dusk anschaue, sehe ich daher nicht nur, ob der Vertrag audited ist, sondern auch, ob das Wallet die aktuellen Schritte, den Hash der Quellkette, den erwarteten Verarbeitungsstatus und die Empfängeradresse gleichzeitig anzeigt. Die offiziellen Dokumente geben einen konkreten Prüfpfad an – das ist ein Pluspunkt. Der nächste Schritt sollte sein, diese Hinweise in jede wichtige Schaltfläche zu integrieren, anstatt darauf zu warten, dass Nutzer nach einem Fehlschlag erst das Help-Center aufschlagen.
Welche Stelle bei der Migration eurer Assets macht euch am meisten Angst: die Freigabe, das falsche Netzwerk auswählen oder ein undurchsichtiger Kontostand nach dem Transfer? Erzähl mal, welche Bedien-Stolperfallen du selbst schon erlebt hast.
$ACE $BTC
