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

Цей практичний посібник зосереджений на п'яти дієвих способах виправлення невдалих транзакцій Solana та кроках, які можуть запобігти повторним помилкам.

Транзакції Solana зазнають невдачі з п'яти причин:

1. Термін дії blockhash закінчився до того, як мережа підтвердила транзакцію
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 поділяються на дві категорії: збої на рівні мережі (закінчення терміну дії blockhash, перевантаження, перевантажені RPC-вузли) та відхилення на рівні програми від смартконтракту або програми, яка запускає застосунок, що ви використовуєте. Помилки допуску прослизання та помилки бюджету обчислень — це відхилення на рівні програми; закінчення терміну дії blockhash та недостатня комісія за пріоритет — це збої на рівні мережі. Виправлення залежить від того, з яким типом ви зіткнулися.

Solana використовує систему обліку часу під назвою Proof of History, яка генерує криптографічну послідовність, яку валідатори використовують для узгодження часу без передачі міток часу один одному. Кожен слот у цій послідовності створює blockhash — код, подібний до мітки часу, вбудований у кожну транзакцію, щоб підтвердити, що транзакція є актуальною. Ця архітектура на основі слотів створює унікальні вікна терміну дії Solana і є тим, що відрізняє її режими збоїв від інших блокчейнів.

Причина 1: Термін дії Blockhash закінчився

Кожна транзакція Solana містить blockhash, який підтверджує, що транзакція була створена нещодавно. Якщо термін дії цього blockhash закінчується до того, як мережа підтвердить транзакцію, Solana повністю її відкидає.

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

Solana використовує Gulf Stream замість традиційної черги транзакцій, що означає, що відкинута транзакція не стає в чергу знову і не чекає. Вона зникає. Ви повинні активно відправити її повторно, ініціювавши транзакцію знову зі свого гаманця або інтерфейсу DEX. Гаманець автоматично отримає новий blockhash при новій відправці. Процедуру повторної відправки див. у Спосіб 3: Повторна відправка зі свіжим Blockhash.

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

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

Причина 2: Занадто низька комісія за пріоритет

Під час перевантаження мережі валідатори Solana — комп'ютери, які обробляють ваші транзакції, — вибирають, які транзакції обробляти першими, виходячи з рівня комісії за пріоритет.

Комісія за пріоритет — це необов'язкові «чайові», що сплачуються валідаторам, які вимірюються в мікролампортах на одиницю обчислень. Один лампорт дорівнює 0,000000001 SOL; один мікролампорт — це мільйонна частина лампорта. Під час періодів інтенсивного трафіку, таких як популярні запуски NFT або різкі зміни ринку, валідатори першими обробляють транзакції з вищою комісією за пріоритет. Транзакції з нульовою або недостатньою комісією за пріоритет відкидаються, а не ставляться в чергу.

Супутня причина помилок недостатньої кількості SOL: Solana вимагає, щоб кожен акаунт підтримував мінімальний Баланс, який називається порогом звільнення від оренди (rent-exempt threshold), щоб залишатися активним у мережі. Якщо баланс вашого гаманця впаде нижче цього порогу після сплати комісії, або якщо транзакція створить новий токен-акаунт без достатньої кількості 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, перш ніж намагатися робити налаштування вручну. Детальні кроки дивіться у розділі Fix 5: Adjust the Compute Unit Budget.

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

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

Причина 4: Перевищено допуск прослизання

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

Це захисний збій, а не втрата. Ваш основний капітал у безпеці; обмін не відбувся. Ви побачите помилку Slippage tolerance exceeded.

Збої через прослизання найчастіше трапляються з волатильними токенами, торговими парами з низькою ліквідністю та під час періодів високої завантаженості, коли затримка між котируванням ціни та виконанням більша. Якщо пул ліквідності має дуже низькі резерви, навіть 5% допуску прослизання може бути недостатньо, оскільки пул не може забезпечити ваш розмір угоди за будь-якою розумною ціною. У такому разі спробуйте зменшити суму обміну або перейти на іншу торгову пару.

Jupiter, Raydium та Orca — це DEX, де цей збій зустрічається найчастіше. Покрокові інструкції з налаштування дивіться у розділі Fix 2: Adjust Your Slippage Tolerance.

Причина 5: Перевантажений вузол RPC

Ваш гаманець Solana підключається до сервера під назвою вузол RPC, щоб подавати транзакції. Уявіть це як поштове відділення, яке передає вашу транзакцію мережі валідаторів. Щоразу, коли ви натискаєте «підтвердити» у Phantom або Backpack, гаманець надсилає вашу транзакцію на вузол RPC, який пересилає її валідаторам.

Безкоштовна публічна кінцева точка RPC Solana має обмеження швидкості та часто перевантажується під час періодів високого попиту. Під час популярного запуску NFT або різкого руху ринку публічні вузли RPC отримують набагато більше запитів, ніж можуть опрацювати, і вони відхиляють транзакції ще до того, як ті дійдуть до валідаторів. Коли це трапляється, ви можете побачити Unable to confirm transaction або зіткнутися з «тихими» збоями без жодного повідомлення про помилку.

Перехід на виділеного провайдера RPC, такого як Helius або QuickNode, обидва з яких пропонують безкоштовні рівні, забезпечує вашим транзакціям надійніший шлях до мережі. Кроки для зміни вашого RPC дивіться у розділі Fix 4: Switch to a Better RPC Endpoint.

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

Підтримуйте список резервних кінцевих точок RPC у конфігурації вашого додатка. Впровадьте логіку автоматичного перемикання при відмові, коли основна кінцева точка повертає помилки або перевищує час очікування. Використовуйте 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. Збільште пріоритетну комісію до Fast або Turbo та подайте повторно
2. Збільште допуск прослизання на 0.5% – 1% і подайте повторно
3. Подайте повторно зі свіжим блокхешем (зачекайте 5 секунд, потім знову ініціюйте з DEX)
4. Переключіться на виділену кінцеву точку RPC у налаштуваннях вашого гаманця
5. Перевірте статус мережі Solana на status.solana.com перед повторною спробою, якщо ви підозрюєте затори

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

Виправлення 1: Збільште пріоритетну комісію

Збільшення пріоритетної комісії є найефективнішим способом вирішення проблеми невдалих транзакцій під час перевантажених періодів. Це сигналізує валідаторам обробляти вашу транзакцію перед запитами з нижчою комісією.

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

Довідник рівнів пріоритетних комісій:

Щоб збільшити пріоритетну комісію в 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, під час отримання хешів блоків у виробничих середовищах.

Виправлення 4: Переключіться на кращий RPC-ендпойнт

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

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

Щоб переключити 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-з'єднання швидші при високому навантаженні.

Виправлення 5: Налаштуйте бюджет одиниць обчислень

Для звичайних користувачів більшість сучасних інтерфейсів DEX, включаючи Jupiter та Raydium, автоматично встановлюють ліміти одиниць обчислень. Якщо ви бачите помилку Compute budget exceeded (Бюджет обчислень перевищено), скористайтеся вбудованою функцією повторного надсилання або оновлення DEX замість ручного налаштування.

Якщо помилка залишається, спробуйте спростити маршрут обміну. Прямий маршрут через один пул використовує менше одиниць обчислень, ніж складний багатоетапний маршрут через чотири або п'ять пулів. У Jupiter шукайте опцію "Тільки прямий маршрут" у налаштуваннях маршрутизації.

Якщо ваш обмін постійно зазнає збоїв для конкретної пари, це може бути пов'язано з тимчасово високим попитом на маршрут. Очікування кілька хвилин і повторне надсилання часто вирішує проблему без будь-яких змін налаштувань.

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

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

Специфічні збої платформи: Phantom, Jupiter, Raydium та Magic Eden

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

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

Збої свопів на Jupiter

Багатоланковий маршрут Jupiter відправляє ваш своп через кілька пулів ліквідності, щоб знайти найкращу ціну. Кожен додатковий крок збільшує споживання одиниць обчислення та створює ще одну точку, де рух ціни може порушити допуск на прослизання.

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

Вбудований селектор пріоритетної комісії Jupiter пропонує варіанти: Звичайна, Швидка, Турбо та Користувацька. Під час будь-якої активної торгової сесії «Швидка» є мінімально рекомендованим налаштуванням. Під час запуску NFT або різкого руху ринку використовуйте «Турбо».

Деякі старіші гаманці не підтримують формат версійних транзакцій Jupiter. Якщо ви бачите помилку формату транзакції замість помилки прослизання або комісії, перевірте, чи оновлено програмне забезпечення вашого гаманця.

Збої свопів на Raydium та Orca

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

Перед підтвердженням будь-якого свопу на Raydium або Orca перевірте відсоток впливу на ціну, показаний в інтерфейсі. Якщо вплив на ціну перевищує 2–3%, обсяг угоди занадто великий для наявної ліквідності в цьому пулі. Зменште суму свопу або розбийте транзакцію на два чи три менші свопи, надіслані послідовно.

Для позицій з концентрованою ліквідністю Whirlpool від Orca прослизання може бути особливо чутливим. Якщо концентрований пул вийшов за межі свого активного цінового діапазону, транзакції зазнаватимуть невдачі незалежно від ваших налаштувань прослизання. У такому разі спробуйте інший пул або маршрут через агрегатор Jupiter, який автоматично знаходить альтернативні шляхи.

Збої мінту на Magic Eden та NFT

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

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

Протокол із трьох кроків для успішного мінту під час запуску з високим попитом:

1. Перед відкриттям вікна мінту встановіть пріоритетну комісію на «Турбо» або на максимальне доступне значення у вашому гаманці
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 або Solana Discord. Якщо багато користувачів одночасно повідомляють про збої, мережа перевантажена. Якщо лише декілька, проблема, швидше за все, на вашому боці.

Чи все одно ви сплачуєте комісію за невдалу транзакцію в Solana?

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

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

Базова комісія становить приблизно 0,000005 SOL за підпис, що дорівнює частці цента при більшості рівнів ціни SOL. Ця комісія компенсує валідаторам обробку спроби транзакції, навіть якщо вона не була успішною. Якщо ви додали пріоритетну комісію, ця сума також списується. Сума токенів, яку ви намагалися обміняти, SOL, які ви намагалися надіслати, або ціна NFT, яку ви намагалися сплатити, ніколи не списувалися.

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

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

1. Скопіюйте підпис транзакції з історії транзакцій вашого гаманця
2. Вставте його в Solana Explorer або Solana FM
3. Знайдіть невдалу транзакцію, яка відображається з червоним статусом помилки
4. Перевірте поле «Комісія», щоб побачити точну суму SOL, яку було стягнуто

Контрольний список перед транзакцією: як запобігти збоям транзакцій у Solana

Виконання цього контрольного списку перед будь-якою чутливою до часу транзакцією займає менше 60 секунд і усуває найпоширеніші причини збоїв.

1. Перевіряйте status.solana.com на наявність активних інцидентів перед будь-якою транзакцією під час волатильних ринкових умов
2. Встановіть пріоритетну комісію принаймні на рівень «Швидка» для будь-якої транзакції під час активних торгових годин; використовуйте «Турбо» для чутливих до часу угод або мінту NFT
3. Переконайтеся, що ваш допуск на прослизання відповідає волатильності токенної пари: 0,5% для стабільних пар, таких як USDC/USDT, від 1% до 2% для токенів із середньою капіталізацією, до 3% для волатильних активів із малою капіталізацією
4. Підтвердьте, що ваш Баланс SOL покриває суму транзакції плюс комісії, а також буфер 0,05 SOL для порогів звільнення від оренди
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 стягує невелику базову комісію за транзакцію, приблизно 0,000005 SOL, навіть якщо транзакція не вдалася, але ваші токени та основна сума обміну не списуються. Транзакції, що тихо відхиляються перевантаженим вузлом RPC до того, як вони потрапляють у мережу, взагалі не стягують комісію, оскільки вони не залишають ончейн-запису. Інструкції щодо перевірки дивіться в розділі Чи ви все ще платите комісію.

Транзакція Solana стає строковою після приблизно 150 слотів, що становить приблизно від 60 до 90 секунд за нормальних умов мережі. Під час перевантаження фактичний час закінчення може здаватися меншим, оскільки валідатори відстають в обробці. Після завершення терміну дії транзакція остаточно скасовується і її потрібно відправити заново з нуля.

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

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

Пріоритетна комісія — це необов’язкові чайові, що виплачуються валідаторам у мікролампортах за обчислювальну одиницю, щоб просунути вашу транзакцію вперед серед поданих із нижчою комісією під час перевантаження. Базова комісія за транзакцію в Solana фіксована та невелика; пріоритетна комісія — це змінний компонент, який визначає, як швидко ваша транзакція буде оброблена. Рівні комісій змінюються залежно від попиту в мережі, тому використовуйте функцію автоматичної оцінки вашого гаманця або API Helius Priority Fee для отримання поточних значень.

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

Ваші кошти не потрібно повертати, тому що вони ніколи не надсилалися. Невдала транзакція Solana не списує ваші токени або суму обміну з вашого гаманця. Транзакція не вдалася до виконання, тому баланс вашого гаманця не змінився, за винятком невеликої базової комісії. Ваша основна сума в безпеці.

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

Помилка симуляції транзакції означає, що Phantom провів попередню перевірку вашої транзакції та спрогнозував, що вона не буде успішною. Phantom блокує подання, щоб запобігти марній витраті комісії за транзакцію, яка не вдасться. Більшість помилок симуляції вказують на реальну проблему у ваших налаштуваннях, наприклад, недостатнє прослизання, низький баланс SOL або відхилення програмою. Іноді застарілі дані про стан спричиняють помилкову відмову; у такому випадку доречно оновити сторінку та спробувати ще раз.

Додайте SOL у свій гаманець і переконайтеся, що ваш баланс перевищує суму транзакції плюс комісії плюс буфер у 0,05 SOL. Помилка про недостатню кількість коштів у Solana не завжди означає, що вам не вистачає SOL лише на комісію. Іноді це означає, що у вас недостатньо SOL для покриття порогу звільнення від оренди, необхідного для створення нового акаунта токена при отриманні токена вперше.

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

Транзакції, що постійно зазнають невдачі, зазвичай вказують на те, що одне і те ж неправильне налаштування повторно подається без коригування. Визначте свою помилку: якщо це Slippage tolerance exceeded, збільште допуск прослизання та подайте заново. Якщо транзакції тихо зникають без повідомлення про помилку, ваша пріоритетна комісія занадто низька. Якщо на status.solana.com відображається активний інцидент, зачекайте відновлення мережі перед повторним поданням.

Збої мінту NFT стаються через те, що тисячі користувачів і ботів подають транзакції одночасно під час вузького вікна запуску, перевантажуючи як публічні кінцеві точки RPC, так і чергу валідаторів. Валідатори відхиляють транзакції з низькою пріоритетною комісією, щоб керувати навантаженням. Встановлення пріоритетної комісії на рівень Turbo та перемикання на виділеного постачальника RPC до відкриття вікна мінту значно покращує показники успіху. Дивіться Magic Eden та помилки мінту NFT для повного протоколу підготовки.

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

Дослідіть SOL на Bybit

Використовуйте сторінку ціни Solana), щоб переглянути поточні ринкові дані SOL, або перейдіть на спотовий ринок SOL/USDT), якщо торгівля на споті відповідає вашим цілям. Торгова активність на Bybit — це не те саме, що подання ончейн-транзакції Solana; мережеві комісії можуть застосовуватися при внесенні або знятті SOL у мережі Solana.

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

Ваш основний капітал є безпечним у кожному з цих сценаріїв. Невдалі транзакції в Solana не призводять до перманентної втрати токенів; споживається лише мінімальна базова комісія. Щоб уникнути повторних збоїв, перегляньте Чек-лист перед транзакцією перед наступним важливим за часом обміном або мінтом.

Шляхи до налаштувань, згадані в цьому посібнику, є актуальними на дату публікації та можуть відрізнятися залежно від гаманця або версії DEX. Рівні комісій залежать від мережевого попиту; використовуйте функцію автоматичного прогнозу вашого гаманця або API Helius Priority Fee API для актуальних значень. Згадки інструментів (Helius, QuickNode, Solana Beach) наведені як варіанти, а не як рекомендації.