Почему транзакции в Solana не проходят: 5 способов решения

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

Транзакции в Solana не проходят по пяти причинам:

1. Срок действия хеша блока истек до того, как сеть подтвердила транзакцию
2. Комиссия за приоритет была слишком низкой для текущего спроса в сети
3. Допуск проскальзывания был нарушен при свопе в DEX
4. Бюджет единиц вычислений закончился в середине выполнения
5. Узел RPC, соединяющий ваш кошелек с сетью, был перегружен

✅ Ваши средства в безопасности

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

На этой странице:

• Почему транзакции в Solana не проходят: что происходит
• 5 основных причин сбоев транзакций в Solana
• Расшифровка сообщений об ошибках Solana
• Как исправить неудачную транзакцию в Solana
• Сбои на конкретных платформах
• Solana не работает? Как проверить статус сети
• Взимается ли комиссия за неудачную транзакцию?
• Контрольный список перед транзакцией
• Часто задаваемые вопросы
• Резюме: подберите решение под вашу ошибку

Почему транзакции в Solana не проходят: что происходит

Наблюдать за тем, как транзакция в Solana не проходит в момент изменения цены, — занятие неприятное, особенно когда сообщение об ошибке не несет никакой полезной информации. Если ваш своп, минт или перевод на Jupiter, Raydium, Orca или Magic Eden завершился ошибкой, причина почти всегда кроется в одной из пяти вещей, и для каждой есть свое решение.

Во всей экосистеме DeFi (децентрализованные финансы) Solana, включая свопы токенов, предоставление ликвидности, протоколы кредитования и минт NFT, сбои транзакций влекут за собой реальные финансовые последствия, так как цены меняются за миллисекунды. Архитектура Solana делает ее быстрее и дешевле большинства блокчейнов, но она также создает сценарии сбоев, которых не ожидают пользователи, привыкшие к Ethereum или другим сетям. В отличие от сетей, где медленные транзакции ждут в очереди, Solana использует протокол пересылки транзакций под названием Gulf Stream, который отбрасывает транзакции, если не может обработать их немедленно. Очереди нет. Неудачные транзакции требуют активной повторной отправки с правильными настройками.

В этом руководстве рассматриваются сбои в вашем кошельке для криптовалюты (таком как Phantom или Backpack), а также на Jupiter, Raydium, Orca и Magic Eden. Если вы подозреваете, что проблемы сегодня у самой Solana, перейдите в раздел статус сети, прежде чем устранять неполадки в настройках.

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

Сбои транзакций в Solana делятся на две категории: сбои на уровне сети (истечение срока действия хеша блока, перегрузка, перегруженные узлы RPC) и программные отказы от смарт-контракта (или программы), в которой работает приложение. Ошибки допуска проскальзывания и превышения бюджета вычислений — это программные отказы; истечение срока действия хеша блока и недостаточная комиссия за приоритет — сетевые. Решение зависит от того, с каким типом ошибки вы столкнулись.

Solana использует систему учета времени под названием Proof of History, которая генерирует криптографическую последовательность, используемую валидаторами для согласования времени без обмена временными метками друг с другом. Каждый слот в этой последовательности создает хеш блока (blockhash) — код, похожий на временную метку, встроенный в каждую транзакцию для подтверждения ее актуальности. Эта архитектура на основе слотов создает уникальные для Solana окна истечения срока действия и отличает ее режимы сбоев от других блокчейнов.

Причина 1: Срок действия хеша блока истек

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

Каждый хеш блока действителен примерно 150 слотов, что в нормальных условиях составляет примерно 60–90 секунд. Во время перегрузки сети валидаторы отстают в обработке, а это означает, что транзакции истекают быстрее в относительном выражении. Вы увидите сообщения об ошибках Blockhash not found или Transaction expired.

Solana использует Gulf Stream вместо традиционной очереди транзакций, а это значит, что отброшенная транзакция не встает в очередь снова и не ждет. Она исчезает. Вы должны активно отправить ее повторно, инициировав транзакцию еще раз из своего кошелька или интерфейса DEX. Кошелек автоматически получит свежий хеш блока при новой отправке. Процедуру повторной отправки см. в разделе Способ 3: Повторная отправка со свежим хешем блока.

⚠️ Примечание для разработчиков

Всегда запрашивайте свежий хеш блока с помощью connection.getLatestBlockhash('confirmed') при каждой попытке повтора. Никогда не используйте один и тот же хеш блока повторно. Используйте уровни обязательств confirmed или finalized в рабочих средах, а не processed, чтобы избежать устаревшего состояния. Определяйте, была ли транзакция отброшена или обработана, вызывая getSignatureStatuses перед каждым повтором.

Причина 2: Слишком низкая комиссия за приоритет

Во время перегрузки сети валидаторы Solana — компьютеры, обрабатывающие ваши транзакции — выбирают, какие транзакции обрабатывать первыми, основываясь на уровне комиссии за приоритет.

Комиссия за приоритет — это необязательное вознаграждение, выплачиваемое валидаторам, измеряемое в микро-лампортах на единицу вычислений. Один лампорт равен 0,000000001 SOL; один микро-лампорт — это одна миллионная часть лампорта. В периоды высокого трафика, такие как запуск популярных NFT или резкие движения рынка, валидаторы в первую очередь обрабатывают транзакции с более высокой комиссией за приоритет. Транзакции с нулевой или недостаточной комиссией отбрасываются, а не ставятся в очередь.

Связанная причина ошибок из-за нехватки SOL: Solana требует, чтобы каждый аккаунт поддерживал минимальный баланс, называемый порогом освобождения от аренды, чтобы оставаться активным в сети. Если баланс вашего кошелька упадет ниже этого порога после оплаты комиссии или если транзакция должна создать новый аккаунт токена без достаточного количества SOL для его обеспечения, вы увидите ошибку Insufficient funds, даже если кажется, что SOL достаточно для самой сделки. Держите буфер в размере 0,05 SOL сверх суммы вашей транзакции.

Вот почему повторная отправка той же транзакции без изменения настроек часто снова заканчивается неудачей. Инструкции по установке правильного уровня комиссии см. в разделе Способ 1: Увеличьте комиссию за приоритет.

⚠️ Примечание для разработчиков

Добавьте ComputeBudgetProgram.setComputeUnitPrice(microLamports) в качестве первой инструкции в вашу транзакцию. Опрашивайте getRecentPrioritizationFees() для динамической оценки, а не используйте статический множитель. Уровни комиссий меняются в зависимости от спроса в сети, поэтому статические значения становятся ненадежными во время всплесков перегрузки. Отслеживайте триггеры отказа, мониторя ошибки HTTP 429 (лимит запросов), 503 (сервис недоступен) и тайм-ауты соединения.

Причина 3: Бюджет вычислений превышен

Каждая транзакция в Solana выполняется в рамках бюджета на обработку, называемого единицами вычислений (compute units), которые измеряют объем вычислительной работы, необходимой для транзакции. Простые переводы потребляют очень мало этого бюджета. Сложные операции, такие как многоэтапный своп в DEX, проходящий через три или четыре пула ликвидности, потребляют значительно больше.

Если у вашей транзакции заканчивается бюджет вычислительных единиц до завершения, Solana отменяет ее. Ошибки, которые вы увидите, это Compute budget exceeded или Program failed to complete.

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

Для большинства пользователей в современных интерфейсах DEX лимиты вычислительных единиц устанавливаются автоматически. Если вы видите ошибку бюджета вычислений, используйте встроенную кнопку повтора DEX перед попыткой ручных настроек. Для получения подробных инструкций см. Исправление 5: Настройка бюджета вычислительных единиц.

⚠️ Примечание для разработчиков

Добавьте ComputeBudgetProgram.setComputeUnitLimit(units) в качестве первой инструкции в транзакцию. Сначала запустите simulateTransaction(), чтобы измерить фактическое потребление вычислительных единиц, затем установите лимит, равный фактическому потреблению, умноженному на 1.1, для 10% буфера. Установка лимита слишком низко приводит к сбоям InstructionError; установка его слишком высоко приводит к пустой трате бюджета комиссий, но не вызывает сбоев.

Причина 4: Превышен допустимый предел проскальзывания

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

Это защитный сбой, а не потеря. Ваши основные средства в безопасности; обмен не был выполнен. Ошибка, которую вы увидите, это Slippage tolerance exceeded.

Сбои из-за проскальзывания чаще всего случаются с волатильными токенами, торговыми парами с низкой ликвидностью и в периоды высокой загруженности сети, когда задержка между вашей ценовой котировкой и исполнением велика. Если пул ликвидности имеет очень низкие резервы, даже 5% допустимого проскальзывания может быть недостаточно, поскольку пул не может обеспечить вашу сделку по какой-либо разумной цене. В этом случае попробуйте уменьшить сумму обмена или переключиться на другую торговую пару.

Jupiter, Raydium и Orca — это DEX, где чаще всего встречается этот сбой. Пошаговые инструкции по настройке см. в Исправлении 2: Настройка допустимого проскальзывания.

Причина 5: Перегруженный RPC-узел

Ваш кошелек Solana подключается к серверу, называемому RPC-узлом, для отправки транзакций. Думайте об этом как об отделении почты, которое передает вашу транзакцию в сеть валидаторов. Каждый раз, когда вы нажимаете «Подтвердить» в Phantom или Backpack, кошелек отправляет вашу транзакцию в RPC-узел, который перенаправляет ее валидаторам.

Бесплатный публичный RPC-endpoint Solana имеет ограничение по частоте запросов и часто перегружен в периоды высокого спроса. Во время популярного запуска NFT или резкого движения рынка публичные RPC-узлы получают гораздо больше запросов, чем могут обработать, и они отбрасывают транзакции, еще до того, как те достигнут валидаторов. Когда это происходит, вы можете увидеть Unable to confirm transaction или столкнуться с тихими сбоями без каких-либо сообщений об ошибках.

Переключение на выделенного RPC-провайдера, такого как Helius или QuickNode, которые предлагают бесплатные тарифы, обеспечивает более надежный путь для ваших транзакций к сети. Инструкции по переключению RPC см. в Исправлении 4: Переключение на лучший RPC-endpoint.

⚠️ Примечание для разработчиков

Ведите список резервных RPC-endpoints в конфигурации вашего приложения. Реализуйте автоматическую логику переключения при возникновении ошибок или таймаутов у основного endpoint'а. Используйте WebSocket signatureSubscribe для мониторинга подтверждения транзакций вместо HTTP-опроса с getSignatureStatuses, так как WebSocket-подписки быстрее и надежнее под нагрузкой.

Расшифровка сообщений об ошибках Solana: Что означает каждое из них

Сообщения об ошибках от неудачных транзакций Solana появляются в журнале активности вашего кошелька (Phantom или Solflare), на Solana Explorer (explorer.solana.com) или на Solana FM (solana.fm). Чтобы найти конкретную неудачную транзакцию, скопируйте сигнатуру транзакции из истории транзакций вашего кошелька и вставьте ее в любой из эксплореров. Неудачная транзакция отображается с красным статусом ошибки и конкретным кодом ошибки.

Перед отправкой любой транзакции Phantom запускает симуляцию, чтобы предсказать, будет ли она успешной. Если эта предварительная проверка не проходит, Phantom отображает Transaction simulation failed и блокирует отправку. Большинство сбоев симуляции указывают на реальную проблему с вашими настройками, но иногда устаревшие данные вызывают ложный сбой. В этом случае подходящим решением будет обновление страницы и однократная повторная отправка.

Как исправить неудачную транзакцию Solana

Чек-лист быстрых исправлений (начните с Исправления 1, если вы не уверены, какое из них применимо):

1. Увеличьте приоритетную комиссию до «Быстрой» или «Турбо» и повторите отправку
2. Увеличьте допустимый предел проскальзывания на 0,5%–1% и повторите отправку
3. Повторите отправку со свежим blockhash (подождите 5 секунд, затем инициируйте снова через DEX)
4. Переключитесь на выделенный RPC-endpoint в настройках вашего кошелька
5. Проверьте статус сети Solana на status.solana.com, прежде чем повторять попытку, если вы подозреваете перегрузку сети

Недостаточная приоритетная комиссия является причиной большинства неудачных транзакций в периоды активной торговли, поэтому Исправление 1 — правильная отправная точка, когда вы не уверены.

Исправление 1: Увеличьте вашу приоритетную комиссию

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

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

Справочник уровней комиссий за приоритет:

Чтобы увеличить комиссию за приоритет в Jupiter (интерфейс может отличаться в зависимости от версии):

1. Откройте Jupiter на jup.ag
2. Нажмите на значок шестеренки настроек в панели обмена
3. Выберите «Комиссия за приоритет»
4. Выберите «Быстрый» или «Турбо», или введите пользовательское значение
5. Повторно отправьте ваш обмен

Чтобы увеличить комиссию за приоритет в Phantom:

1. Откройте кошелек Phantom
2. Перейдите в «Настройки»
3. Выберите «Транзакции»
4. Установите «Скорость транзакции» на «Высокая» или «Пользовательская»
5. Вернитесь к вашему DEX и повторно отправьте транзакцию

Для Raydium нажмите на значок шестеренки в интерфейсе обмена, выберите «Комиссия за приоритет», выберите более высокий уровень и повторно отправьте транзакцию. Таблица Специфичные для платформы сбои показывает точный путь навигации для каждой платформы.

⚠️ Примечание для разработчиков

Добавьте ComputeBudgetProgram.setComputeUnitPrice(microLamports) как первую инструкцию в вашу транзакцию. Вызывайте getRecentPrioritizationFees(), чтобы получить текущие процентили сетевой комиссии, вместо использования статического множителя. Переплата тратит SOL, но не приводит к сбоям транзакций.

Исправление 2: Настройте допустимое проскальзывание

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

⚠️ Важное предупреждение

Установка проскальзывания выше 3–5% на парах токенов с низкой ликвидностью подвергает вас атакам MEV-сэндвич, когда боты обнаруживают вашу ожидающую транзакцию и проводят ее первыми, чтобы извлечь прибыль. Увеличивайте проскальзывание постепенно, а не все сразу.

Чтобы настроить проскальзывание в Jupiter (интерфейс может отличаться в зависимости от версии):

1. Откройте Jupiter и нажмите на значок шестеренки настроек
2. Выберите «Допустимое проскальзывание»
3. Увеличьте текущее значение на 0,5%–1% (например, с 0,5% до 1,5%)
4. Повторно отправьте ваш обмен

Для Raydium: нажмите на значок шестеренки, выберите «Проскальзывание», введите измененный процент и повторно отправьте транзакцию. Для Orca: нажмите «Настройки», настройте «Допустимое проскальзывание» и повторно отправьте транзакцию. Таблица Специфичные для платформы сбои показывает точный путь навигации для каждого DEX.

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

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

Исправление 3: Повторная отправка с новым хэшем блока

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

Поскольку Solana использует Gulf Stream вместо традиционной очереди транзакций, потерянную транзакцию нельзя «отменить». Транзакция потеряна. Новую транзакцию необходимо создать с нуля.

Для обычных пользователей (Phantom, Jupiter, Raydium):

1. Подождите 5–10 секунд после сбоя
2. Не нажимайте «Отправить» повторно на том же экране подтверждения
3. Вернитесь в интерфейс обмена и начните транзакцию заново
4. Ваш кошелек автоматически получает новый хэш блока при повторной отправке

Перед повторной отправкой: проверьте Solana Explorer (explorer.solana.com), чтобы убедиться, что транзакция на самом деле не была успешной. Вставьте вашу подпись транзакции в строку поиска. Если транзакция отображается как подтвержденная, не отправляйте ее повторно.

⚠️ Примечание для разработчиков

Получите новый хэш блока с помощью connection.getLatestBlockhash('confirmed') перед каждой попыткой повторной отправки. Реализуйте экспоненциальную задержку: ждите 1 секунду перед первой повторной отправкой, 2 секунды перед второй, 4 секунды перед третьей. Установите максимальное количество попыток в 5, прежде чем выводить ошибку пользователю. Используйте уровни подтверждения confirmed или finalized, а не processed, при получении хэшей блоков в производственных средах.

Бесплатная общедоступная RPC-точка Solana (api.mainnet-beta.solana.com) имеет ограничения по частоте запросов и часто перегружена в периоды высокого спроса, из-за чего отправленные транзакции с большей вероятностью будут отброшены до достижения валидаторов.

Выделенные RPC-провайдеры, такие как Helius и QuickNode, как правило, обеспечивают более высокую надежность, чем общедоступный RPC мейннета Solana, во время перегрузок. Оба провайдера предлагают бесплатные тарифы, подходящие для индивидуальных пользователей.

Чтобы сменить RPC в Phantom (интерфейс может отличаться в зависимости от версии):

1. Откройте кошелек Phantom
2. Перейдите в «Настройки»
3. Выберите «Настройки разработчика»
4. Выберите «Изменить RPC-конечную точку»
5. Введите URL вашей конечной точки Helius или QuickNode
6. Подтвердите и повторно отправьте вашу транзакцию

Чтобы сменить RPC в Solflare:

1. Откройте кошелек Solflare
2. Перейдите в «Настройки»
3. Выберите «Сеть»
4. Выберите «Пользовательский RPC» и введите URL вашей конечной точки
5. Сохраните и повторно отправьте вашу транзакцию

⚠️ Примечание для разработчиков

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

Для обычных пользователей большинство современных интерфейсов DEX, включая Jupiter и Raydium, автоматически устанавливают лимиты вычислительных блоков. Если вы видите ошибку «Превышен бюджет вычислений», используйте встроенную функцию повторной отправки или обновления DEX, а не вручную настраивайте параметры.

Если ошибка сохраняется, попробуйте упростить маршрут обмена. Прямой маршрут через один пул использует меньше вычислительных блоков, чем сложный многоэтапный маршрут через четыре или пять пулов. В Jupiter ищите опцию «Только прямой маршрут» в настройках маршрутизации.

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

⚠️ Примечание для разработчиков

Добавьте ComputeBudgetProgram.setComputeUnitLimit(units) как первую инструкцию в транзакцию. Сначала выполните simulateTransaction(), чтобы измерить фактическое потребление вычислительных блоков, затем установите лимит, равный фактическому потреблению, умноженному на 1,1 (10% запас). Установка лимита слишком низкого значения приводит к сбоям InstructionError; установка слишком высокого значения тратит бюджет комиссии без сбоев.

Специфичные для платформы сбои: Phantom, Jupiter, Raydium и Magic Eden

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

Сбои свопов в Jupiter

Мультихоповая маршрутизация Jupiter отправляет ваш своп через несколько пулов ликвидности для поиска лучшей цены. Каждый дополнительный «хоп» увеличивает потребление вычислительных единиц и создает еще одну точку, где движение цены может выйти за пределы допустимого проскальзывания.

Двумя наиболее распространенными сбоями в Jupiter являются превышение допустимого проскальзывания на волатильных парах токенов и ошибка Transaction simulation failed из-за недостаточной приоритетной комиссии. Оба исправляются в меню настроек (иконка шестеренки) в Jupiter перед повторной отправкой.

Встроенный переключатель приоритетной комиссии Jupiter предлагает варианты Normal, Fast, Turbo и Custom. Во время любой активной торговой сессии Fast является минимальной рекомендуемой настройкой. Во время запуска NFT или резкого движения рынка используйте Turbo.

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

Сбои свопов в Raydium и Orca

Сбои AMM Raydium и Orca чаще всего связаны с высоким ценовым воздействием в пулах с ограниченной ликвидностью. Пул не может обработать ваш объем сделки по разумной цене даже при щедрых настройках проскальзывания.

Перед подтверждением любого свопа в Raydium или Orca проверяйте процент ценового воздействия, указанный в интерфейсе. Если ценовое воздействие превышает 2–3%, объем сделки слишком велик для доступной ликвидности в этом пуле. Уменьшите сумму свопа или разделите транзакцию на два или три небольших свопа, отправляя их последовательно.

Для позиций с концентрированной ликвидностью Whirlpool в Orca проскальзывание может быть особенно чувствительным. Если концентрированный пул вышел за пределы своего активного ценового диапазона, транзакции будут завершаться ошибкой независимо от настроек проскальзывания. В этом случае попробуйте другой пул или маршрут через агрегатор Jupiter, который автоматически находит альтернативные пути.

Сбои минта на Magic Eden и NFT

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

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

Трехэтапный протокол для успешного минта во время запусков с высоким спросом:

1. Перед открытием окна минта установите приоритетную комиссию на Turbo или максимальное доступное значение в вашем кошельке
2. Переключитесь с публичного RPC Solana на выделенного провайдера, такого как Helius или QuickNode (бесплатных тарифов достаточно)
3. Держите страницу минта полностью загруженной, а подключение кошелька предварительно одобренным; отправляйте транзакцию сразу после открытия минта, не дожидаясь обновления страницы

Ваша основная сумма SOL возвращается автоматически, если транзакция минта не удалась. Списывается только небольшая сетевая комиссия, примерно 0,000005 SOL. Некоторые проекты также используют механизмы разрешенных списков (allow-list) и Candy Guards, поэтому если транзакции постоянно не проходят даже с правильными настройками, убедитесь, что вы подходите для текущей фазы минта.

Solana упала? Как проверить статус сети

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

Трехэтапная проверка статуса:

1. Перейдите на status.solana.com, официальную страницу статуса сети Solana, и проверьте наличие отчетов об инцидентах от Solana Foundation.
2. Перейдите на Solana Beach и проверьте показатель транзакций в секунду (TPS) в реальном времени и среднее время подтверждения. Высокая частота отказов при активном TPS указывает на перегрузку сети, а не на сбой.
3. Проверьте r/solana или Discord Solana. Если многие пользователи одновременно сообщают о сбоях, сеть перегружена. Если таких сообщений мало, проблема, скорее всего, на вашей стороне.

Взимается ли комиссия за неудачную транзакцию в Solana?

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

Ваши токены в безопасности. Транзакция прервалась до того, как был выполнен какой-либо своп или перевод.

Базовая комиссия составляет примерно 0,000005 SOL за сигнатуру, что при большинстве цен на SOL составляет долю цента. Эта комиссия компенсирует валидаторам обработку попытки транзакции, даже если она не увенчалась успехом. Если вы включили приоритетную комиссию, эта сумма также списывается. Количество токенов, которые вы пытались обменять, SOL, которые вы пытались отправить, или цена NFT, которую вы пытались заплатить, никогда не списывались.

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

Чтобы проверить, какая именно комиссия была списана за любую неудачную транзакцию:

1. Скопируйте сигнатуру транзакции из истории транзакций вашего кошелька
2. Вставьте ее в Solana Explorer или Solana FM
3. Найдите неудачную транзакцию, помеченную красным статусом ошибки
4. Проверьте поле Fee, чтобы увидеть точную сумму SOL, которая была списана

Чек-лист перед транзакцией: как предотвратить сбои в сети Solana

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

1. Проверяйте status.solana.com на наличие активных инцидентов перед любой транзакцией в условиях волатильного рынка
2. Устанавливайте приоритетную комиссию как минимум на уровень «Fast» для любых транзакций в активные торговые часы; используйте «Turbo» для срочных сделок или минта NFT
3. Убедитесь, что ваше допустимое проскальзывание соответствует волатильности пары токенов: 0,5% для стабильных пар, таких как USDC/USDT, от 1% до 2% для токенов со средней капитализацией и до 3% для волатильных токенов с малой капитализацией
4. Подтвердите, что ваш баланс SOL покрывает сумму транзакции плюс комиссии, а также запас в 0,05 SOL для порога освобождения от аренды (rent-exempt)
5. Для срочных или дорогостоящих транзакций переключитесь с публичного RPC Solana на выделенного провайдера, такого как Helius или QuickNode (оба предлагают бесплатные тарифы)
6. Для минта NFT: настройте приоритетную комиссию и RPC до открытия окна минта, а не во время него
7. Для крупных свопов DEX: проверяйте процент ценового воздействия перед подтверждением; если ценовое воздействие превышает 2–3%, уменьшите сумму свопа или разделите ее на несколько транзакций поменьше
8. Доверяйте встроенному оптимизатору комиссий вашего DEX, если он доступен; Jupiter, Raydium и Orca предлагают автоматические рекомендации по комиссиям, которые адаптируются к текущему состоянию сети

⚠️ Примечание разработчика

В продакшн dApps реализуйте оценку вычислительных юнитов на основе симуляции, а не статических ограничений. Динамически опрашивайте getRecentPrioritizationFees() и обновляйте рекомендацию по комиссии при каждой отправке транзакции. Реализуйте отказ от RPC, чтобы ваше приложение автоматически переключалось на резервную конечную точку. Никогда не используйте повторно хеши блоков при попытках повторной отправки.

Частые вопросы: Пять решений для неудачных транзакций Solana

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

Что вызывает сбой транзакции Solana?

Транзакции Solana терпят неудачу по пяти причинам: истечение срока действия блока, недостаточная приоритетная комиссия, исчерпание лимита вычислительных юнитов, нарушение допуска проскальзывания или перегрузка RPC-узла. Сбои на уровне сети требуют увеличения приоритетной комиссии и повторной отправки. Отклонения на уровне программы требуют корректировки параметров транзакции, таких как допустимое проскальзывание или сумма обмена. См. 5 основных причин сбоев транзакций Solana для полного объяснения каждой из них.

Платите ли вы комиссии за неудачную транзакцию Solana?

Да. Solana взимает небольшую базовую комиссию за транзакцию, примерно 0.000005 SOL, даже когда транзакция терпит неудачу, но ваши токены и основная сумма обмена не списываются. Транзакции, молчаливо отброшенные перегруженным RPC-узлом до достижения сети, вообще не взимают комиссию, поскольку они не оставляют никакого следа в сети. См. Платите ли вы еще комиссии для инструкций по проверке.

Как долго транзакция Solana может истечь?

Транзакция Solana истекает примерно через 150 слотов, что составляет около 60-90 секунд в нормальных сетевых условиях. Во время перегрузки эффективное время истечения срока действия может ощущаться короче, поскольку валидаторы отстают в обработке. После истечения срока действия транзакция навсегда отклоняется и должна быть отправлена заново с нуля.

Что такое хеш блока в Solana?

Хеш блока — это код, похожий на временную метку, встроенный в каждую транзакцию Solana, который подтверждает, что транзакция была создана недавно. Валидаторы используют его для проверки того, что транзакция актуальна и не была повторно воспроизведена из предыдущей сессии. Хеши блоков истекают примерно через 150 слотов; после этого транзакция отклоняется с ошибкой Blockhash not found или Transaction expired.

Что такое вычислительные юниты в Solana?

Вычислительные юниты — это мера обрабатываемых ресурсов, потребляемых транзакцией в Solana. Простые переводы используют небольшое количество; сложные многоходовые DEX обмены используют значительно больше. Если транзакция исчерпывает свой бюджет вычислительных юнитов до завершения, Solana отменяет ее и возвращает ошибку Compute budget exceeded. Современные DEX интерфейсы автоматически устанавливают лимиты вычислительных юнитов для большинства пользователей.

Что такое приоритетная комиссия в Solana?

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

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

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

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

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

Почему Solana отбрасывает транзакции вместо постановки в очередь?

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

Что означает «симуляция транзакции не удалась» в Phantom?

Сбой симуляции транзакции означает, что Phantom провел предварительный тест вашей транзакции и предсказал, что она не будет успешной. Phantom блокирует отправку, чтобы вы не потратили комиссию на транзакцию, которая потерпит неудачу. Большинство сбоев симуляции указывают на реальную проблему с вашими настройками, такую как недостаточное проскальзывание, низкий баланс SOL или отказ программы. Иногда устаревшие данные состояния вызывают ложный сбой; в этом случае уместно обновить страницу и отправить повторно один раз.

Как исправить нехватку средств в Solana?

Добавьте SOL на свой кошелек и убедитесь, что ваш баланс превышает сумму транзакции плюс комиссии плюс буфер в 0,05 SOL. Ошибка нехватки средств в Solana не всегда означает, что у вас закончились SOL только для комиссии. Иногда это означает, что у вас недостаточно SOL для покрытия порога освобождения от аренды, необходимого для создания новой учетной записи токена при первом получении токена.

Безопасны ли мои деньги, если транзакция Solana не удалась?

Ваши основные средства в безопасности. Токены или SOL, которые вы пытались отправить или обменять, остаются в вашем кошельке точно так же, как они были. Неудачная транзакция Solana не выполняет перевод, обмен или чеканку, поэтому ваш баланс не изменился. Могла быть взита только небольшая базовая комиссия за транзакцию, обычно менее 0,001 доллара США.

Почему моя транзакция Solana продолжает сбои, даже после повторной попытки?

Повторяющиеся сбои транзакций обычно указывают на то, что одна и та же неправильная настройка повторяется без корректировки. Определите свою ошибку: если это «Превышен допуск проскальзывания», увеличьте допуск проскальзывания и повторно отправьте. Если транзакции отбрасываются молча, без сообщения об ошибке, ваша приоритетная комиссия слишком низкая. Если status.solana.com показывает активный инцидент, дождитесь восстановления сети, прежде чем повторно отправлять.

Почему транзакции Solana сбоят во время NFT чеканки?

Сбои NFT чеканки происходят потому, что тысячи пользователей и ботов одновременно отправляют транзакции в течение узкого окна запуска, насыщая как публичные RPC-конечные точки, так и очередь валидаторов. Валидаторы отбрасывают транзакции с низкой приоритетной комиссией для управления нагрузкой. Установка приоритетной комиссии на «Турбо» и переход на выделенного RPC-провайдера до открытия окна чеканки значительно повышает процент успешных попыток. См. Magic Eden и сбои NFT-чеканки NFT для полного протокола подготовки.

Что такое допуск проскальзывания на DEX Solana?

Допуск проскальзывания — это максимальное изменение цены, которое вы готовы принять между моментом запроса обмена и моментом его выполнения. Если цена токена выходит за пределы этого порога, смарт-контракт автоматически отменяет обмен, чтобы защитить вас от получения значительно худшей цены, чем было указано. Типичные настройки варьируются от 0,5% для пар стабильных токенов до 2% или 3% для волатильных активов. Установка значения выше 3-5% для пар с низкой ликвидностью увеличивает риск подверженности атакам MEV-сэндвич.

Изучите SOL на Bybit

Используйте страницу цены SOL) для просмотра текущих рыночных данных SOL или получите доступ к спот-рынку SOL/USDT), если торговля на споте соответствует вашим целям. Bybit торговая активность не совпадает с отправкой ончейн-транзакции Solana; сетевые комиссии все еще могут применяться при пополнении или выводе SOL в сети Solana.

Краткое изложение: Сопоставьте вашу ошибку с правильным решением

Каждый сбой транзакции Solana соответствует одной из пяти основных причин, и каждая имеет свое конкретное решение.

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

Пути настроек, указанные в этом руководстве, актуальны на дату публикации и могут отличаться в зависимости от кошелька или версии DEX. Уровни комиссий меняются в зависимости от нагрузки на сеть; используйте функцию автооценки вашего кошелька или Helius Priority Fee API для получения текущих значений. Ссылки на инструменты (Helius, QuickNode, Solana Beach) представлены как варианты (options), а не как рекомендации.