Я ещё раз просмотрел(а) руководство по миграции в основную сеть для @Dusk и заметил(а) одну очень легко упускаемую деталь: то, что вы нажали Approve в кошельке, ещё не означает, что $DUSK уже переведён в основную сеть Dusk. Настоящий запуск миграции происходит на следующем шаге — Execute transaction. Любая остановка между этими двумя действиями может создать у пользователя ощущение, что активы «застряли».
Официальный процесс такой: ERC-20 в сети Ethereum или BEP-20 DUSK в BNB Chain блокируются в миграционном контракте, а затем соответствующие нативные монеты выдаются на указанный адрес в основной сети Dusk. Пользователю нужно подготовить самостоятельный EVM-кошелёк, аккаунт Dusk, а также ETH или BNB для оплаты комиссий в исходной сети; после подтверждения транзакции обычно ещё требуется подождать обработки. Аккаунты на бирже, как правило, не могут напрямую выполнить эту операцию через WalletConnect — сначала средства нужно вывести в кошелёк, который вы контролируете.
Сам механизм несложный, настоящие подводные камни — в границах операции. Во-первых, разрешение — это лишь выдача лимита контракту, оно не переводит токены автоматически; во-вторых, токены в исходной сети имеют 18 знаков после запятой, а DUSK в основной сети — 9, поэтому сумма миграции округляется вниз до минимальной единицы LUX, а остаток меньше 1 LUX остаётся в исходном кошельке; в-третьих, если баланс не пришёл, сначала нужно проверить, успешно ли прошла транзакция Execute, а не повторно выдавать разрешение.
Такая схема односторонней блокировки с последующей выдачей понятнее, чем если бы пользователю пришлось самому искать кроссчейн-пул, но она всё равно сводит две сети, два кошелька и два подтверждения в один процесс. Для опытных пользователей это лишь ещё один взгляд на интерфейс, а для новичков фраза «разрешение успешно» может быть понята как «миграция завершена».
Поэтому, когда я смотрю на #dusk и его миграцию в основную сеть, я обращаю внимание не только на то, проходил ли контракт аудит, но и на то, показывает ли кошелёк текущий шаг, хэш исходной сети, ожидаемый статус обработки и адрес получения одновременно. В официальной документации чётко указан путь проверки — это плюс; следующий шаг — встроить такие подсказки в каждую ключевую кнопку, а не отправлять пользователя в центр помощи уже после ошибки.
А вас при миграции активов больше всего пугает что: разрешение, выбор неверной сети или непрозрачный статус зачисления? Расскажите, на каких операциях вы уже спотыкались.
$ACE $BTC
Официальный процесс такой: ERC-20 в сети Ethereum или BEP-20 DUSK в BNB Chain блокируются в миграционном контракте, а затем соответствующие нативные монеты выдаются на указанный адрес в основной сети Dusk. Пользователю нужно подготовить самостоятельный EVM-кошелёк, аккаунт Dusk, а также ETH или BNB для оплаты комиссий в исходной сети; после подтверждения транзакции обычно ещё требуется подождать обработки. Аккаунты на бирже, как правило, не могут напрямую выполнить эту операцию через WalletConnect — сначала средства нужно вывести в кошелёк, который вы контролируете.
Сам механизм несложный, настоящие подводные камни — в границах операции. Во-первых, разрешение — это лишь выдача лимита контракту, оно не переводит токены автоматически; во-вторых, токены в исходной сети имеют 18 знаков после запятой, а DUSK в основной сети — 9, поэтому сумма миграции округляется вниз до минимальной единицы LUX, а остаток меньше 1 LUX остаётся в исходном кошельке; в-третьих, если баланс не пришёл, сначала нужно проверить, успешно ли прошла транзакция Execute, а не повторно выдавать разрешение.
Такая схема односторонней блокировки с последующей выдачей понятнее, чем если бы пользователю пришлось самому искать кроссчейн-пул, но она всё равно сводит две сети, два кошелька и два подтверждения в один процесс. Для опытных пользователей это лишь ещё один взгляд на интерфейс, а для новичков фраза «разрешение успешно» может быть понята как «миграция завершена».
Поэтому, когда я смотрю на #dusk и его миграцию в основную сеть, я обращаю внимание не только на то, проходил ли контракт аудит, но и на то, показывает ли кошелёк текущий шаг, хэш исходной сети, ожидаемый статус обработки и адрес получения одновременно. В официальной документации чётко указан путь проверки — это плюс; следующий шаг — встроить такие подсказки в каждую ключевую кнопку, а не отправлять пользователя в центр помощи уже после ошибки.
А вас при миграции активов больше всего пугает что: разрешение, выбор неверной сети или непрозрачный статус зачисления? Расскажите, на каких операциях вы уже спотыкались.
$ACE $BTC
