Контракт может быть корректным, и при этом мой вызов DuskVM все равно может завершиться неудачей из‑за двух символов.

Входные данные DuskVM не отправляются в виде читаемого JSON. Это байты, закодированные в формате rkyv, и Forge использует драйвер офлайн-данных контракта, чтобы превратить что-то вроде 42 в те байты, которые контракт реально ожидает.

Сложность в передаче. Forge дает мне это закодированное значение в виде hex с префиксом 0x. SDK может захотеть, чтобы этот префикс сохранялся. В Wallet Rusk для параметра --fn-args требуется, чтобы я его убрал.

Так что я могу проверить логику контракта, убедиться в корректности WASM, правильно закодировать аргумент, а затем сломать реальный вызов, передав ровно те же байты в неправильной форме транспортировки.

Это та интеграционная ошибка, которую я бы защищал сильнее всего. Не потому что она драматична, а потому что все выше по цепочке выглядит здорово. Функция существует. Схема правильная. Значение правильное. Неудача живет на границе между драйвером данных и отправителем.

Если бы я собирал приложение DuskVM, я бы нормализовал аргументы вызова один раз и протестировал эту границу для каждого пути отправки, который я поддерживаю.

Два символа никогда не должны быть причиной того, что корректное действие контракта превращается в неудачную пользовательскую транзакцию.

#dusk $DUSK @Dusk