Транзакцію відправлено — і користувач дивиться на статус Pending наступні 10 хвилин. Це нормально для блокчейну, але ненормально — не отримати сповіщення, коли транзакція підтвердилася або зафейлилася. Відстеження статусу транзакції — це real-time задача з кількома рівнями: polling блокчейну, WebSocket-з'єднання, push-сповіщення при фінальному статусі. Без своєчасних оновлень користувачі втрачають довіру, а в криптогаманцях з великим трафіком (наприклад, 8000 транзакцій на день) затримка навіть у 5 секунд створює негативний досвід.
Наші інженери з 5+ річним досвідом у блокчейн-проектах реалізували відстеження для 15+ криптогаманців. Сертифіковані Apple та Google, працювали з Ethereum, Bitcoin, Solana та іншими мережами, інтегрували WebSocket через Alchemy WebSocket API та Infura, налаштовували push-сповіщення через APNs та FCM. Гарантуємо стабільну роботу та своєчасні оновлення статусу.
Як виглядає життєвий цикл транзакції?
Ethereum-транзакція проходить через стани: submitted → pending (mempool) → confirmed (1 confirmation) → finalized (12+ confirmations) → failed (reverted / dropped). Bitcoin: mempool → 1 confirmation → 6 confirmations (finalized). Solana — значно швидше: слоти по ~400ms, processed → confirmed → finalized за секунди. На клієнті потрібно показувати поточний стан та кількість підтверджень.
| Блокчейн | Час блоку | Підтверджень для фіналізації | Середній час фіналізації |
|---|---|---|---|
| Ethereum | 12-15 сек | 12 (як 0x) або 64 (як 1) | ~3 хв (12 блоків) |
| Bitcoin | ~10 хв | 6 | ~60 хв |
| Solana | ~400 мс | 32 | ~13 сек |
Які стратегії отримання статусу існують?
| Стратегія | Затримка | Навантаження на клієнт | Навантаження на сервер |
|---|---|---|---|
| Polling (3–5 сек) | 3–5 сек | Високе (часті запити) | Високе (RPC виклики) |
| WebSocket | <1 сек | Низьке (постійне з'єднання) | Середнє (підписки) |
| Webhook (Alchemy/Infura) | <1 сек | Нульове (тільки push) | Низьке (сервер отримує подію) |
Polling кожні 3–5 секунд при відкритому екрані — нормально. У фоні — тільки через silent push або WebSocket API. Економія на інфраструктурі до 40% при використанні WebSocket замість частого polling.
Polling через node RPC
// iOS — polling статусу ETH транзакції через JSON-RPC func pollTransactionStatus(txHash: String) async throws -> TransactionStatus { let params: [AnyEncodable] = [txHash, false] let receipt = try await ethClient.call(method: "eth_getTransactionReceipt", params: params) if receipt == nil { return .pending // Ще в mempool } let confirmations = try await getConfirmationsCount(txHash: txHash) return confirmations >= requiredConfirmations ? .confirmed : .confirmingWith(count: confirmations) } Чому WebSocket швидше за polling?
WebSocket забезпечує миттєву передачу даних при появі нового блоку, тоді як polling має затримку до 5 секунд. Для критичних транзакцій WebSocket — кращий вибір. Ми допомагаємо обрати оптимальний варіант під ваш бюджет та вимоги.
WebSocket підписка через Alchemy / Infura / QuickNode
// Бекенд — підписка на подію через Alchemy WebSocket const { createAlchemyWeb3 } = require("@alch/alchemy-web3"); const web3 = createAlchemyWeb3(process.env.ALCHEMY_WS_URL); async function watchTransaction(txHash, userId) { const subscription = web3.eth.subscribe('newBlockHeaders'); subscription.on('data', async (blockHeader) => { const receipt = await web3.eth.getTransactionReceipt(txHash); if (receipt) { subscription.unsubscribe(); await updateTransactionStatus(txHash, receipt.status ? 'confirmed' : 'failed'); await sendPushNotification(userId, txHash, receipt.status); } }); } Як налаштувати відстеження статусу транзакції через WebSocket?
- На сервері піднімаємо WebSocket ендпоінт, авторизований за токеном користувача.
- На клієнті встановлюємо з'єднання при переході на екран списку транзакцій.
- Підписуємося на події по
tx_hash— сервер надсилає оновлення статусу. - При отриманні фінального статусу закриваємо з'єднання.
- Повторно підключаємося при повторному відкритті екрану або після помилки.
// Android — підписка на статус транзакції через WebSocket class TransactionStatusSocket( private val token: String, private val okHttpClient: OkHttpClient ) { fun subscribe(txHash: String): Flow<TransactionStatus> = callbackFlow { val ws = okHttpClient.newWebSocket( Request.Builder() .url("wss://api.yourwallet.app/ws/tx/$txHash") .header("Authorization", "Bearer $token") .build(), object : WebSocketListener() { override fun onMessage(webSocket: WebSocket, text: String) { val status = json.decodeFromString<TransactionStatusUpdate>(text) trySend(status.status) if (status.isFinal) close() } override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) { close(t) } } ) awaitClose { ws.close(1000, "Subscription ended") } } } Progress індикатор підтверджень
Для ETH відображаємо прогрес до 12 підтверджень. Використовуємо ProgressView з градієнтом від оранжевого до зеленого зі збільшенням count. Дизайн транзакції в різних статусах:
- pending — анімований spinner, жовтий акцент
- confirming — progress bar з кількістю підтверджень
- confirmed — зелена галочка, анімація
- failed — червоний, причина помилки якщо доступна (revert reason з receipt)
Push-сповіщення при зміні статусу
При фінальному статусі надсилаємо push користувачу:
{ "title": "Транзакція підтверджена", "body": "0.05 ETH відправлено на 0x742d...3B8C", "data": { "screen": "transaction_detail", "tx_hash": "0xabc123...", "status": "confirmed" } } Для failed транзакції — окремий шаблон з описом причини (revert reason або dropped from mempool).
Як влаштована обробка dropped транзакцій?
Транзакція може зникнути з mempool якщо gas price була занадто низькою. Через 15–30 хвилин без підтвердження — транзакція вважається dropped. Потрібно detectити це:
suspend fun checkDroppedTransactions() { val pendingTxs = transactionDao.getPendingOlderThan(minutes = 20) pendingTxs.forEach { tx -> val receipt = ethClient.getTransactionReceipt(tx.hash) if (receipt == null) { transactionDao.updateStatus(tx.hash, TransactionStatus.DROPPED) pushService.notifyUser(tx.userId, "Транзакція не потрапила в блок", tx.hash) } } } Що входить в роботу
Аналіз поточної архітектури гаманця та вибір стратегії (polling/WebSocket/webhook). Інтеграція з блокчейн-нодами (Infura, Alchemy, QuickNode) або власним вузлом. Реалізація клієнтської логіки: polling/WebSocket клієнт для iOS та Android. Розробка progress bar для відображення кількості підтверджень. Налаштування push-сповіщень (APNs, FCM) при фінальному статусі. Обробка dropped транзакцій та помилок (revert reason, timeout). Тестування на тестових мережах (Goerli, Sepolia) та mainnet. Документація та передача вихідного коду.
Терміни та вартість
Базова реалізація відстеження з polling та push-сповіщеннями займає 6–10 робочих днів. Повний цикл з WebSocket, progress bar, обробкою dropped транзакцій та кастомними push — від 2 тижнів. Вартість розраховується індивідуально після аналізу проекту. Зв'яжіться з нами для консультації та точної оцінки.
Ми гарантуємо якість, надаємо підтримку після запуску. Досвід наших розробників підтверджено сертифікатами Apple та Google. Отримайте безкоштовну консультацію з архітектури відстеження для вашого криптогаманця.