Наблюдение за тем, как swap становится красным, — один из самых неприятных моментов в Solana, особенно в сети, которая позиционируется как быстрая и практически бесплатная. Появляющееся сообщение об ошибке редко объясняет, что именно пошло не так в терминах, понятных кому-либо за пределами разработки протоколов.

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

Что такое несостоявшаяся транзакция Solana?

Несостоявшаяся транзакция Solana — это транзакция, которая успешно дошла до валидатора, была включена в блок, а затем отклонена во время выполнения, поскольку какое-то условие, от которого она зависела, перестало выполняться. Она по-прежнему навсегда записывается onchain с привязанным кодом ошибки и логами программы.

Wallets обычно отображают это в виде красного баннера или простой надписи «failed» без каких-либо дополнительных подробностей. Чтобы найти истинную причину, вставьте сигнатуру транзакции в эксплорер, например Solscan, и изучите программные логи, в которых указана конкретная инструкция, вызвавшая откат, и причина этого.

Что особенно важно, выполнение на Solana атомарно. Если какая-либо отдельная инструкция внутри транзакции выдает ошибку, все изменения состояния, которые эта транзакция должна была совершить, полностью отменяются, поэтому балансы ваших токенов остаются точно такими же, какими были до этого. Единственное, что вы теряете, — это небольшая комиссия, уплаченная за попытку.

Эта атомарность является продуманной функцией безопасности, а не конструктивным дефектом. Она гарантирует, что вы никогда не столкнетесь с незавершенным swap, когда токены списаны с одной стороны, но ничего не получено с другой, что было бы гораздо худшим исходом, чем чистый и полностью отмененный отказ.

Отброшенные и несостоявшиеся транзакции Solana

Эти два исхода выглядят практически одинаково внутри интерфейса wallet, однако у них противоположные причины и они требуют противоположных мер. Умение различать их является самым полезным шагом диагностики для любого пользователя Solana, который не требует ничего, кроме внимательности.

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

Механизм, лежащий в основе большинства отмен — это истечение срока действия blockhash. Каждая транзакция Solana ссылается на недавний blockhash, который остаётся действительным в течение примерно 150 блоков, или около 60–90 секунд в реальном времени. Пропустите это узкое окно, и валидаторы сразу же отклонят транзакцию. Это правило существует для предотвращения атак повторного воспроизведения (replay attacks).

Пример А (Неудачный): Вы делаете swap USDC на SOL на Meteora, но цена выходит за пределы заданного вами проскальзывание во время выполнения транзакции, поэтому программа отменяет её. Попытка фиксируется в ончейн с явной ошибкой проскальзывания, а с вас взимается только комиссия сети.

Пример Б (Отброшенный): Вы покупаете токен на pump.fun во время ажиотажа при запуске, но ваша конечная точка RPC отстает на несколько слотов от вершины цепочки, и blockhash истекает до того, как какой-либо лидер увидит транзакцию. Ничего не появляется ни в одном обозревателе, и комиссия не взимается.

Сколько на самом деле транзакций в Solana терпят неудачу?

Заголовки новостей о том, что половина всех транзакций в Solana завершается неудачно, одновременно точны и практически бессмысленны, поскольку они сваливают в кучу огромные объемы автоматизированного арбитражного спама и обычную активность в кошелёк, которую реальные пользователи создают каждый день.

Академические исследования, опубликованные в 2025 году, наконец-то поставили точку в этом вопросе с помощью точных цифр, а не оценок. Рецензируемое исследование 1,5 миллиарда неудачных транзакций в 72 миллионах блоков показало, что бот-аккаунты дают сбой в 58,43% случаев, в то время как аккаунты, управляемые людьми, дают сбой гораздо скромнее — в 6,22%.

Эта цифра для человека имеет огромнейшее значение для контекста. Она находится на уровне типичного для Ethereum диапазона от 1% до 3% и комфортно ниже показателей отказов в 21% и 15,4%, наблюдаемых в Base и Arbitrum. Это переводит репутацию Solana как ненадежной сети в разряд статистических аномалий, вызванных ботами, а не проблемы пользовательского опыта.

Концентрация подтверждает ту же мысль. На десять программ, генерирующих больше всего сбоев, приходится 77,95% от общего объема, причем на долю пула ликвидности Raydium Liquidity Pool V4 приходится 21,69%, поскольку боты-снайперы спешат торговать недавно созданными пулами еще до завершения их инициализации.

Однако в часы пик перегрузка по-прежнему бьет сильно. Когда волатильность мемкоинов подскакивает, измеренные показатели успешности транзакций (без учета голосования) падают примерно до 76%. Это означает, что примерно каждая четвертая транзакция реального пользователя завершается неудачно, несмотря на обнадеживающие долгосрочные средние показатели, которые дают академические данные.

Что данные говорят о причинах сбоев транзакций

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

Типы ошибок, лежащих в основе сбоев транзакций в Solana, распределяются следующим образом:

• Цена или прибыль не достигнуты (47,99%): Допуск на проскальзывание был превышен или арбитражный маршрут перестал быть прибыльным в промежутке между отправкой и выполнением, что спровоцировало защитный откат, заложенный DEX агрегаторами.
• Недействительный статус (19,19%): Транзакция была направлена на аккаунт или пул ликвидности в состоянии, не допускающем эту операцию (часто это неинициализированный пул или замороженный аккаунт токена).
• Истечение срока действия (17,72%): Упомянутый blockhash устарел до того, как валидатор успел его обработать (ончейн-индикатор перегрузки, задержки конечных точек RPC или медленной подписи на стороне клиента).
• Неверный входной аккаунт (3,27%): Требуемые адреса аккаунтов отсутствовали, были указаны в неправильном порядке или не имели авторизации — частая проблема на сложных маршрутах, затрагивающих множество программ одновременно.
• Неверные входные параметры (2,55%): Аргумент вышел за пределы диапазона, принимаемого программой (например, минимальная сумма вывода установлена на уровне нуля в инструкции swap на Raydium).
• Недостаточно средств (2,16%): В кошельке не хватило SOL для покрытия перевода, комиссий и rent — это ошибка, которая сильнее всего затрагивает реальных пользователей, а не ботов.
• Нехватка ресурсов (0,49%): Транзакция исчерпала свой вычислительный бюджет или превысила пределы среды выполнения по памяти в куче (характерно для многошаговых маршрутов, затрагивающих десятки аккаунтов).

Один вывод заслуживает особого внимания всех, у кого возникает соблазн просто заплатить больше. Неудачные транзакции на самом деле платят более высокие комиссии, чем успешные, потребляя при этом меньше вычислительных единиц, и все равно попадают в блоки глубже. Бессмысленная трата денег на решение проблемы без правильного расчета вычислительных ресурсов очевидно не работает.

Распространенные причины сбоев транзакций в Solana

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

Вот наиболее частые причины неудачных транзакций в Solana:

• Жесткое проскальзывание: Установка допуска ниже того, которого требует текущая волатильность, гарантирует отмену операций с токенами с низкой ликвидностью, где цены могут изменяться на несколько процентов между подписанием и выполнением.
• Низкий priority fee: Валидаторы упорядочивают транзакции по цене вычислительного блока (compute unit), поэтому транзакция с заниженной ставкой вытесняется и опускается вглубь блоков в периоды высокой нагрузки.
• Истекший blockhash: Медленное подписание, отстающий RPC или простые колебания при подтверждении запроса могут исчерпать окно актуальности до того, как транзакция дойдет до лидера.
• Превышение вычислительных лимитов: Многоэтапные маршруты через несколько пулов децентрализованных бирж могут превысить лимит по умолчанию в 200 000 compute unit на инструкцию и завершиться с ошибкой.
• Перегруженный RPC: Публичные эндпоинты разделяются огромным количеством пользователей и резко деградируют во время запусков, отбрасывая транзакции еще до их отправки валидаторам.
• Недостаточный баланс: Комиссии, rent для новых токен-аккаунтов и priority fee списываются в SOL, поэтому кошельки, на которых есть только обмениваемый токен, сразу завершаются с ошибкой.
• Тонкая ликвидность: Крупные ордера в мелких пулах не могут быть исполнены по приемлемой цене, что вызывает ту же проблему с недостаточной ликвидностью, знакомую по другим блокчейнам.
• Замороженные аккаунты: Злонамеренные создатели токенов могут замораживать переводы после привлечения покупателей. Этот паттерн honeypot проявляется как ошибка недействительного статуса при попытке продажи.

Как исправить сбои транзакций в Solana

Как только вы определили, в чем проблема: в логике выполнения или доставке в сети, решением обычно становится конкретная настройка, а не общий призыв попробовать снова.

Эти настройки решают большинство проблем с транзакциями в Solana:

• Разумно увеличьте slippage: Установите допуск на уровне от 1% до 3% для волатильных токенов, согласившись на чуть менее выгодную цену в обмен на успешное выполнение транзакции вместо потраченной впустую комиссии.
• Динамически настраивайте priority fee: В нормальных условиях транзакции проходят при ставке от 1 000 до 5 000 микролапортов за compute unit, в то время как во время запусков и ликвидаций этот показатель может достигать 100 000 и более.
• Точно рассчитывайте compute units: Сначала проведите симуляцию, а затем установите лимит, близкий к фактическому потреблению, поскольку цена покупает приоритет, а завышенный лимит лишь расходует ресурс впустую.
• Смените провайдера RPC: Выделенные эндпоинты от Helius, Triton или QuickNode стабильно передают данные в условиях перегрузки, когда стандартные публичные ноды уже перегружены и отклоняют запросы.
• Обновите данные перед повторной попыткой: Получайте новый blockhash для каждой попытки, а не отправляйте повторно исходный, который, скорее всего, уже истек и снова молча завершится с ошибкой.
• Держите резервный SOL: Solflare рекомендует оставлять нетронутыми по крайней мере 0,05 SOL, чего достаточно для комфортной оплаты базовых комиссий, priority fee и любых депозитов rent.
• Предпросмотр перед подписанием: Симуляция в кошельке бесплатно отсекает обреченные на провал транзакции, в то время как ончейн-ошибка все равно стоит базовой комиссии и прикрепленного priority fee.

Сколько стоит неудачная транзакция в Solana?

Финансовые потери от неудачной транзакции минимальны, что является одним из реальных структурных преимуществ Solana перед блокчейнами с более высокими комиссиями. Каждая транзакция влечет за собой базовую комиссию в размере 0,000005 SOL за подпись, и эта плата взимается независимо от того, завершится ли выполнение успешно или будет отменено на каком-то этапе.

Дополнительные расходы применяются в зависимости от ситуации, а не повсеместно. Открытие нового токен-аккаунта требует разового депозита rent в размере около 0,002 SOL, в то время как любой прикрепленный priority fee рассчитывается как цена compute unit, умноженная на лимит compute unit, а затем деленная на миллион.

С февраля 2025 года 100% priority fee поступают напрямую валидаторам, а не сжигаются наполовину, после активации изменения в управлении SIMD-0096. Сама базовая комиссия по-прежнему делится поровну между сжиганием и производителем блока, который включил вас в него.

Пример: Вы открываете позицию с leverage по SOL через платформу perps, цена выходит за рамки вашего допуска во время обработки транзакции, и она отменяется. Ваш залог остается нетронутым, а вы теряете лишь долю цента. Более подробную информацию см. в нашем руководстве по комиссиям gas в Solana.

Как Firedancer и Alpenglow меняют картину

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

1. Firedancer

Firedancer, независимый клиент валидатора, написанный с нуля на C и C++ компанией Jump Crypto, вышел в основную сеть в декабре 2025 года после масштабного тестирования. К середине 2026 года примерно 14% stake сети работали на полноценном Firedancer, а еще 26% — на гибридном варианте Frankendancer.

Разнообразие клиентов напрямую влияет на надежность. Еще совсем недавно абсолютно каждый валидатор использовал ПО на базе Agave, а это значит, что одна не обнаруженная вовремя ошибка могла разом остановить всю цепочку. Два по-настоящему независимых решения устраняют эту единую точку отказа и добавляют ценный запас пропускной способности во время всплесков трафика.

2. Alpenglow

Alpenglow — это гораздо более серьезное изменение, которое еще ожидает внедрения. Одобренное валидаторами в сентября 2025 года при поддержке 98,27%, оно полностью заменяет как Tower BFT, так и Proof of History, нацеливаясь на финализацию транзакций примерно за 150 миллисекунд по сравнению с примерно 12,8 секундами в текущей архитектуре.

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

Однако формирование комиссий все еще остается нерешенным вопросом. Фиксированная базовая комиссия Solana за подпись никак не реагирует на спрос, а редизайн на основе ресурсов, который оценивал бы вычисления и доступ к аккаунтам по отдельности, активно обсуждался на протяжении всего 2026 года без выработки окончательной спецификации.

Лучшие практики для предотвращения сбоев транзакций в Solana

Профилактика неизменно превосходит диагностику в Solana, поскольку настройки, вызывающие сбои, выбираются задолго до того, как что-либо попадет к валидатору. Несколько привычек, выработанных до начала торговли, устранят большинство сбоев, которые иначе прервали бы вашу сессию в самый разгар и стоили бы вам цен входа.

1. Поддерживайте актуальность настройки

Устаревшее программное обеспечение и общая публичная инфраструктура вызывают сбои, которые не имеют абсолютно никакого отношения к выбранным вами торговым параметрам. Разберитесь с этим фундаментом в первую очередь:

• Регулярно обновляйте кошельки: Phantom, Solflare и Backpack часто выпускают улучшения оценки комиссий, а устаревшие версии пропускают исправления совместимости для изменений среды выполнения и валидаторов.
• Используйте частную конечную точку: Выделенный доступ к RPC стоит недорого и устраняет главный источник отмененных транзакций во время запусков и других событий с высоким трафиком.
• Очищайте зависшие сеансы: Перезапуск расширения или браузера решает проблему кэшированных состояний подключения, которые незаметно вызывают повторяющиеся сбои спустя долгое время после восстановления сетевых условий.

2. Настройте параметры перед подтверждением

Большинство возвратов определяются настройками, которые вы выбираете перед подписью, а не тем, что происходит в сети в этот конкретный момент:

• Сопоставляйте проскальзывание с волатильностью: Недавно запущенным токенам требуется существенно более широкий допуск, чем устоявшимся парам, где жесткие настройки защищают вас без значительного риска срыва исполнения.
• Симулируйте сложные маршруты: Предварительно просматривайте swap, затрагивающие несколько пулов, так как симуляция абсолютно бесплатно выявляет проблемы с потреблением вычислительных ресурсов и состоянием аккаунта.
• Пополняйте буфер комиссий: Держите SOL отдельно от своей торговой позиции, чтобы депозиты rent и приоритетные ставки никогда не конкурировали с активами, которыми вы собираетесь торговать.

3. Выбирайте правильное время для транзакций

Время отправки транзакции варьируется почти так же сильно, как и способ ее настройки, поскольку сетевая конкуренция сильно концентрируется в несколько прогнозируемых временных окон:

• Избегайте окон запуска: Запуски meme coin, клеймы airdrop и каскады liquidation генерируют бот-спам, который сильнее всего вытесняет обычных пользователей.
• Разбивайте крупные операции: Разделение многошаговых действий DeFi на отдельные транзакции удерживает каждое из них в пределах лимитов вычислений и изолирует любой сбой до одного компонента.

Заключение

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

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

С учетом того, что Firedancer уже запущен в mainnet, а Alpenglow приближается к активации, причины сбоев на уровне сети неуклонно сокращаются из года в год. Остается лишь конфигурация, и эта часть уравнения всегда находилась полностью под вашим контролем.