Слово «Removed» в трейд-мониторинге легко прочитать как «failed» (провал), но когда я вижу RUES-событие для @Dusk , я сначала останавливаюсь: то, что транзакция покинула локальный mempool, не означает, что её отклонили в блокчейне. Это не игра словами. В официальном описании Dusk transactions/removed означает только то, что транзакция вышла из локального mempool какого-то узла; причина может быть в том, что она попала в блок, была заменена конфликтующей транзакцией с более высоким gasPrice, устарела, вытеснена по емкости или просто конфликтующая транзакция ушла. По одной этой записи система не сообщает вам окончательный итог.

Это заставило меня иначе взглянуть на developer experience для $DUSK : когда монитор переводит removed в failure, бэкенд слишком рано предупреждает, а когда трактует removed как success, можно пропустить по-настоящему вытеснённые транзакции. Поле статуса фактически разделяет «что происходит перед глазами узла» и «что в итоге запомнил журнал (账本)». Сценарии под нагрузкой вполне обычны: пользователь отправляет перевод, кошелёк получает removed и показывает «попробуйте ещё раз»; затем он отправляет вторую транзакцию и только тогда обнаруживает, что первая уже попала в блок. В итоге он переплачивает gas, а службе поддержки приходится объяснять, какая из транзакций была действительной. Если выводить ошибки, не глядя на账本, а только на события, локальное представление раздувается до факта.

Поэтому я не буду считать removed из RUES признаком failure. Документация для @Dusk даёт более надёжное направление: проверить транзакцию и состояние блоков, прежде чем решать, стоит ли повторять отправку. Дальше я посмотрю, разделяет ли кошелёк для пользователя отображение «удалено локально» и «конечный результат» — именно эта деталь и помогает Dusk уберечь пользователей от лишних ошибок. #dusk