Кальтер / Блог

Почему неуспешная транзакция Solana всё равно может стоить SOL

Отделяем результат исполнения от сетевой комиссии Solana и разбираем учебный расчёт base fee и priority fee.

Материал подготовлен с помощью ИИ. Источники, учебные примеры и расчёты проверены редакцией перед публикацией.

Условная последовательность неуспешной транзакции Solana; ошибка исполнения не означает автоматически отсутствие комиссии.
Условная последовательность неуспешной транзакции Solana; ошибка исполнения не означает автоматически отсутствие комиссии.

В Solana транзакция может завершиться execution error, а комиссия всё равно списывается. В актуальной документации fee payer оплачивает базовую и, если она задана, priority fee до исполнения; результат инструкции не отменяет уже начисленную комиссию (Solana Fee Structure).

Отличай такой случай от отказа preflight-проверки до отправки или операции, которая вообще не попала в сеть. Сообщение интерфейса «ошибка» ещё не доказывает, что on-chain комиссия была списана: проверяй реальную транзакцию и её fee.

Сверь ошибку и fee отдельно

Открой подпись транзакции в обозревателе и проверь сеть, статус, fee payer, количество подписей и compute budget instructions. В логах смотри, на каком этапе вернулась ошибка. Ошибка программы объясняет, почему не выполнилось действие, а поле комиссии показывает отдельную сетевую стоимость обработки.

Для legacy/v0 транзакций в текущей документации расчёт выглядит так:

total fee = base fee + prioritization fee
base fee = количество учитываемых подписей × lamports_per_signature
priority fee = ceil(CU price × CU limit / 1 000 000)

ceil означает округление вверх до целого lamport. В описанном документацией формате v1 priority fee задаётся как абсолютная сумма в lamports, а не через CU price×limit; не применяй эту формулу к нему автоматически.

Страница, проверенная 1 ноября 2026 года, указывает текущую base rate 5 000 lamports за подпись; значение и параметры могут измениться. В учебном сценарии одна подпись и CU price=2 000 micro-lamports, CU limit=200 000 дают:

base = 1 × 5 000 = 5 000 lamports
priority = 2 000 × 200 000 / 1 000 000 = 400 lamports
total = 5 400 lamports

Это синтетический расчёт по формуле, а не комиссия конкретной транзакции. Priority fee считается по запрошенному CU limit, не фактическому использованию; высокий лимит может увеличить плату даже если вычислений оказалось меньше.

Попроси ИИ разделить статус выполнения и комиссию, пересчитать base и priority fee только при наличии всех входных данных, не обещать возврат и не объявлять ошибку доказательством сбоя кошелька. Передай signature, fee payer, signatures, CU limit/price и инструкцию с ошибкой; недостающее поле модель должна пометить неизвестным.

Проверь, не создал ли интерфейс повторную транзакцию, прежде чем отправлять новую. Не вводи подпись в случайный сайт и не делись приватными ключами. Текущие fee rules перепроверяй перед расчётом, так как runtime-параметры обновляются. Для других сетей и общей терминологии комиссий есть обзор сетевых gas fees; статусы ожидания разобраны отдельно в руководстве по pending-переводу.