| finality_status | execution_status | Вывод |
|---|---|---|
| ACCEPTED_ON_L2 | SUCCEEDED | Вызов успешен и блок финализирован консенсусом L2 |
| ACCEPTED_ON_L2 | REVERTED | Откат включён в финализированный блок L2 |
| ACCEPTED_ON_L1 | SUCCEEDED | Успешный вызов входит в состояние, достигшее L1 |
| ACCEPTED_ON_L1 | REVERTED | Откат остаётся откатом после достижения L1 |
- finality_status
- ACCEPTED_ON_L2
- execution_status
- SUCCEEDED
- Вывод
- Вызов успешен и блок финализирован консенсусом L2
- finality_status
- ACCEPTED_ON_L2
- execution_status
- REVERTED
- Вывод
- Откат включён в финализированный блок L2
- finality_status
- ACCEPTED_ON_L1
- execution_status
- SUCCEEDED
- Вывод
- Успешный вызов входит в состояние, достигшее L1
- finality_status
- ACCEPTED_ON_L1
- execution_status
- REVERTED
- Вывод
- Откат остаётся откатом после достижения L1
Accepted описывает место, а не результат вызова
До исполнения `starknet_getTransactionStatus` может показать `RECEIVED` или `CANDIDATE`. Для исполненной транзакции `finality_status` проходит `PRE_CONFIRMED`, `ACCEPTED_ON_L2` и `ACCEPTED_ON_L1`, а `execution_status` принимает `SUCCEEDED` либо `REVERTED`. Интерфейс, который показывает только слово accepted, скрывает половину ответа.
При `REVERTED` Starknet включает транзакцию в блок. Nonce аккаунта увеличивается, комиссия взимается до точки отказа, а изменения execution-stage откатываются. Поэтому повтор с прежним nonce обычно не является исправлением.
Receipt связывает статус с наблюдаемыми последствиями
Что прочитать до любого повтора
- 1Закрепить сеть и hash
Запишите chain, RPC endpoint и полный transaction_hash. Сначала вызовите starknet_getTransactionStatus: NOT_RECEIVED у другого узла может отражать локальную видимость RECEIVED, а не окончательное отсутствие.
- 2Получить receipt после исполнения
Вызовите starknet_getTransactionReceipt и сохраните finality_status, execution_status, block number, block hash при его наличии, actual_fee и тип транзакции. У pre-confirmed receipt block hash может отсутствовать.
- 3Найти причину
Для REVERTED сохраните revert reason из ответа поддерживаемой версии RPC. Не заменяйте её текстом кошелька.
- 4Проверить nonce
Прочитайте nonce аккаунта на состоянии после блока. Включённый откат потребляет nonce, хотя вызов контракта не сохранил изменения.
- 5Проверить цель
Прочитайте ожидаемое storage, balance или ownership на том же состоянии. Отсутствие эффекта подтверждает, что нужен исправленный новый запрос транзакции.
Общий гайд по подтверждениям объясняет уровни сети, а чтение calldata помогает проверить вызванный метод и аргументы. Для Starknet решающим остаётся сочетание двух статусов и post-state.
Новый запрос собирают только после доказанной причины
| Наблюдение | Действие | Контроль |
|---|---|---|
| RECEIVED или CANDIDATE | Не менять nonce вслепую; повторить запрос к тому же провайдеру | Появился receipt либо подтверждённое исключение из mempool |
| PRE_CONFIRMED + SUCCEEDED/REVERTED | Сохранить receipt и ждать требуемой финальности | Появился ACCEPTED_ON_L2/L1 либо подтверждена смена canonical history |
| ACCEPTED_ON_L2/L1 + REVERTED | Исправить revert reason, взять следующий nonce и симулировать | Новый receipt SUCCEEDED и post-state изменён |
| NOT_RECEIVED на одном RPC | Проверить исходный узел и другие доказательства отправки | Отсутствие подтверждено, nonce/state не изменены |
| ACCEPTED_ON_L2/L1 + SUCCEEDED, UI не обновился | Не повторять | Прямое чтение state и событий подтверждает результат |
- Наблюдение
- RECEIVED или CANDIDATE
- Действие
- Не менять nonce вслепую; повторить запрос к тому же провайдеру
- Контроль
- Появился receipt либо подтверждённое исключение из mempool
- Наблюдение
- PRE_CONFIRMED + SUCCEEDED/REVERTED
- Действие
- Сохранить receipt и ждать требуемой финальности
- Контроль
- Появился ACCEPTED_ON_L2/L1 либо подтверждена смена canonical history
- Наблюдение
- ACCEPTED_ON_L2/L1 + REVERTED
- Действие
- Исправить revert reason, взять следующий nonce и симулировать
- Контроль
- Новый receipt SUCCEEDED и post-state изменён
- Наблюдение
- NOT_RECEIVED на одном RPC
- Действие
- Проверить исходный узел и другие доказательства отправки
- Контроль
- Отсутствие подтверждено, nonce/state не изменены
- Наблюдение
- ACCEPTED_ON_L2/L1 + SUCCEEDED, UI не обновился
- Действие
- Не повторять
- Контроль
- Прямое чтение state и событий подтверждает результат
Стоп-сигналы
- слово accepted показано без execution_status;
- receipt ещё pre-confirmed, но результат уже называют финальным;
- REVERTED повторяют со старым nonce без проверки post-state;
- Transaction hash not found на другом RPC принимают за доказанное отсутствие.
Списавшийся gas при откате не делает перевод успешным. Похожую границу между включением и исполнением можно увидеть в Ethereum, но названия полей и lifecycle нельзя переносить между сетями.
Если кошелёк предлагает новую подпись, снова проверьте получателя, calldata, лимиты ресурсов и nonce. Старый accepted receipt храните рядом с новым хешем, чтобы расследование не превратилось в цепочку неразличимых попыток.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Starknet Documentation — Transactions Starknet · Проверено 30 августа 2026 г. в 15:55 GMT+5
- Starknet JSON-RPC specification StarkWare · Проверено 30 августа 2026 г. в 15:55 GMT+5