EVM transaction broadcast timed out: what should you do?

`eth_sendRawTransaction` submits an already signed transaction and normally returns its hash. A timeout means the caller did not receive a definitive response before its deadline. It does not establish that submission failed, and a returned hash establishes submission through that request, not inclusion in a block.

Treat transport errors, JSON-RPC errors, a returned hash, a transaction lookup, and a receipt as different evidence. If the request has a JSON-RPC error, retain its code and message. Do not convert a missing HTTP response into a made-up rejection reason. The JSON-RPC specification separates a result from an error response, but a connection failure may deliver neither to the caller.

Sign once, then durably record the intended chain, sender, nonce, transaction hash, exact signed bytes, intended action, and submission state before sending. Use a wallet or signing library that computes the hash of the signed transaction locally. The Ethereum transaction guide describes the signed raw form and its hash.

Give each business operation its own durable identifier and link it to this transaction. That lets a restarted worker resume the same operation instead of creating a fresh transfer. Keep signing keys outside application logs, and restrict access to the saved transaction record. A transaction hash alone is enough for a lookup, but the exact signed bytes are needed if your recovery policy permits a controlled rebroadcast.

First call `eth_getTransactionReceipt` with the saved hash. A receipt identifies an included transaction. Record its blockHash, blockNumber, and status. A status of 0x0 is a mined execution failure, not a broadcast failure. The failed-transaction guide explains the next diagnosis step.

If the receipt is null, call `eth_getTransactionByHash`. A transaction object with no block identity can indicate a pending transaction visible to that RPC view. If both lookups return null, the outcome remains unknown. Pending transactions are not a globally complete database, and a lookup miss does not prove that no peer saw the submission. Recheck at a bounded interval and retain the original hash for later reconciliation.

If you need another submission attempt, send the identical signed bytes with eth_sendRawTransaction. This preserves the same transaction hash and intended nonce. Treat an already-known response as evidence to investigate, not as permission to create a new transaction. Bound the number of attempts, back off between them, and stop if the operation reaches a terminal state.

Do not automatically rebuild and sign a fresh transaction after a timeout. A changed nonce can authorize a second action. Changing fees or other fields while keeping the nonce creates a different transaction hash that must be tracked as a separate candidate. Whether a replacement is accepted depends on network and transaction-pool rules, so use an explicit replacement policy and retain every candidate hash. The Ethereum transaction reference defines the nonce as the sender's sequential transaction counter.

`eth_getTransactionCount` returns an account nonce at a selected block reference. Compare latest with the transaction's nonce to detect whether confirmed chain state has moved past it. That does not identify which transaction used the nonce. A pending count may include transactions visible to the queried node, but it is not proof of global propagation or final inclusion.

If the confirmed nonce has advanced, search your own candidate hashes and verify the included transaction before marking the business action complete. If the nonce has not advanced, continue the bounded lookup and rebroadcast policy. Do not infer success from nonce movement alone, especially if another signer can use the same account.

A returned broadcast hash or a pending lookup is an intermediate state. Require a receipt for the expected transaction, inspect its execution status, and check the block against the finality policy for that chain and business action. A receipt can move or disappear during a reorganization, so retain block identity and reconcile before treating an unfinalized result as irreversible.

If a different transaction with the same sender and nonce was included, inspect its destination, value, and input. Do not credit the original action merely because the nonce was consumed. If no definitive inclusion appears within the application's recovery window, move the operation to an explicit unresolved state for investigation rather than reporting a confirmed failure or signing another action automatically.

1. Before sending, persist the chain, sender, nonce, hash, exact signed bytes, and business-operation ID.
2. On timeout, mark submission unknown. Preserve the transport error and request time.
3. Query the receipt by the saved hash, then the transaction by hash if no receipt exists.
4. If still unknown, retry lookups within a bounded window. Rebroadcast only the identical signed bytes under a controlled policy.
5. Track any intentionally created replacement under its own hash. Never discard the original candidate.
6. Confirm the included transaction, receipt status, block identity, and required finality before completing the business action.
7. Escalate unresolved outcomes with both the operation ID and all candidate hashes.

The central rule is simple: a timeout changes what you know about submission, not what the chain has done. Reconcile the original signed transaction before authorizing another one.