A reliable transaction lifecycle, from broadcast to finality.
A digital-assets platform was losing transactions to static gas prices and had no visibility once a transaction was broadcast. We built a lifecycle engine covering construction and broadcast, dynamic EIP-1559-aware gas estimation, and real-time status tracking through to confirmation, for both native ETH and ERC-20 token transactions, reused across every EVM chain on the platform.
EIP-1559 aware
Dynamic gas estimation, not static gas prices
Broadcast → Final
Full status tracking, on every transaction
Native + ERC-20
One engine for ETH and token transfers alike
Fewer stuck txns
Down from a recurring support burden
The challenge
Broadcast, then a black box.
Gas prices were set statically per chain, for both native ETH transfers and ERC-20 token transactions, even though token transfer and approve calls don’t cost the same gas as a simple ETH transfer and vary by contract. When network conditions moved, transactions went out underpriced and sat unconfirmed, or overpriced and cost customers more than they needed to pay. Neither direction was something the platform could see happening in real time.
Once a transaction was broadcast, the platform’s visibility mostly ended there. Support couldn’t tell a customer whether a transaction was still pending, had failed, or had been replaced, and a single RPC provider outage could mean a transaction never made it to the network at all.
Every EVM chain the platform supported handled this differently, so the problem, and the fixes, kept getting rebuilt chain by chain instead of solved once.
Our approach
Three workstreams. One lifecycle, reused across every chain.
We built the transaction lifecycle as a single engine, construction and broadcast, gas fee estimation, and status tracking, designed to be reused across every EVM chain rather than re-implemented each time one was added.
01
Transaction construction & broadcast
Built the construction layer for both native ETH transfers and ERC-20 token transactions: nonce management under concurrent load, calldata assembly for transfer and approve calls, and signing, then broadcast through redundant RPC providers so a single provider outage doesn't mean a dropped transaction.
02
Gas fee estimation
Replaced static gas prices with dynamic, EIP-1559-aware estimation, base fee and priority fee from recent block and mempool data, with a legacy gasPrice fallback for chains that don't support 1559. ERC-20 calls are simulated per contract rather than assumed, since token transfer and approve gas costs vary chain to chain and contract to contract.
03
Status tracking & confirmation
Tracked every transaction from broadcast through to a configurable confirmation depth, handling reorgs and distinguishing pending, confirmed, failed and replaced states. For ERC-20 transfers, confirmation is tied to decoding the Transfer event in the receipt logs, not just the transaction succeeding on-chain.
The outcome
Visibility from broadcast to finality.
Transactions are priced dynamically, broadcast redundantly, and tracked through to confirmation, on every EVM chain the platform runs, off a single shared engine.
Dynamic, EIP-1559-aware gas estimation replacing static gas prices, cutting underpriced and stuck transactions
Redundant broadcast path across multiple RPC providers, so a single provider outage no longer means a dropped transaction
Real-time status tracking from broadcast through to confirmation, including reorg handling
Clear pending, confirmed, failed and replaced states surfaced to product and support, instead of a black box
Nonce management that holds up under concurrent transaction load without transactions getting stuck out of order
Per-contract gas simulation for ERC-20 transfers and approvals, instead of assuming token transaction costs match native transfers
One lifecycle engine reused across every EVM chain on the platform, for native and ERC-20 transactions alike, not rebuilt each time a chain was added
We used to get support tickets asking if a transaction had actually gone through. Now gas pricing, broadcast and confirmation are tracked end to end, on every chain we run, and that question doesn’t come up anymore.
Transactions getting stuck, or hard to track?
Transaction construction and broadcast, dynamic gas fee estimation, and status tracking through to confirmation, built as one reusable engine across your EVM chains. Start with a discovery call.