eth_getTransactionByHash
Blink intercepts eth_getTransactionByHash and resolves it in two steps:
The request is forwarded to an Ethereum node. If the node knows the transaction — mined, or sitting in its mempool — that response is returned unchanged.
If — and only if — the node returns
null, Blink checks its own records. If the transaction was submitted through Blink within the last 3 hours — or the last 96 seconds if it used revert protection — Blink returns a synthetic pending response built from the raw transaction you submitted.
The node always wins. A transaction body or an error from the node is passed through untouched; only a definitive null reaches Blink's own store.
eth_getGaslessTransactionByHash is an alias for this method and behaves identically.
A transaction still pending more than a minute after submission is almost always either nonce-blocked — an earlier nonce from the same sender has not landed yet — or underpriced for current network conditions.
Neither is terminal. If the base fee falls or the sender tops up their balance, Blink can still get the transaction on chain inside its retention window — though a revert-protected submission has only 96 seconds of that window, so gas pricing matters more there. We recommend strong nonce management and being generous with the gas price.
Reading the response
result with a non-null blockNumber
Mined. Comes straight from the node.
result with blockNumber: null
Not mined yet. Either the node's own mempool entry, or a transaction Blink is holding that the node has not seen. It remains includable — see the note above.
result: null
Neither the node nor Blink knows of the transaction within its retention window. See below.
result: null does not mean the transaction failed. It covers several distinct situations this method cannot tell apart:
never submitted, or submitted somewhere other than Blink
submitted more than 3 hours ago, or more than 96 seconds ago with revert protection
submitted to Blink and rejected at ingress (in which case your original
eth_sendRawTransactioncall returned an error)included and then reorged out
replaced by another transaction with the same sender and nonce
See Determining a final outcome for how to resolve these.
Submission lifecycle
A transaction submitted through Blink is first offered exclusively to Blink's integrated builders, then submitted more widely for a further set of blocks. It stays eligible for inclusion throughout the 3-hour window.
Revert protection is the exception. A revert-protected submission is sent to builders as a bundle targeting a fixed range of upcoming blocks, and is not retried past it — so it is dropped after 96 seconds rather than staying eligible for 3 hours. From then on this method returns null for it.
The synthetic pending response
When Blink answers from its own records rather than the node, the response is built from the raw transaction bytes you submitted. It is a well-formed transaction object:
blockHash,blockNumberandtransactionIndexarenull, as for any pending transaction.toisnullfor contract creation, as for any node response.v,randsare returned as0x0. Blink deliberately withholds signature values for transactions that have not yet been included — see below.
The remaining fields are decoded from the transaction you submitted. Field-level parity with a node's own response is not guaranteed for a synthetic body; treat the node's response as authoritative once it has one.
Why signature values are withheld
A transaction's signature, combined with the other fields, is enough to re-encode the complete signed transaction. If Blink returned real signature values for a transaction still in flight, anyone who learned the hash could reconstruct it and submit it to builders themselves — bypassing the protection you submitted it for, or using it to front-run or sandwich you.
Blink therefore zeroes v, r and s until the transaction is on chain. The fields are still present, so the response keeps the shape a node returns. Once the transaction is mined, the response comes straight from the node and carries the real values.
Every other field is reported faithfully, and the hash is the real transaction hash, so you can still match the response to your submission.
Determining a final outcome
A non-null blockNumber is the only positive terminal signal. Wait for your required confirmation depth before treating it as final.
Otherwise:
Compare
eth_getTransactionCount(from, "latest")with your transaction's nonce. A count greater than the nonce means the nonce was consumed by a different transaction, so yours will never land.If the nonce is still free and the transaction is still pending, it is waiting on gas price or on an earlier nonce — see the note at the top. Raising the fee or clearing the blocking nonce resolves it faster than waiting does.
Past the retention window — 3 hours, or 96 seconds with revert protection — Blink no longer holds the transaction and returns
null.
If Blink's own lookup fails, the method returns a JSON-RPC error rather than null. Treat an error as "retry the poll", never as "the transaction is gone".
Example request
Example response — pending
Example response — mined
Returned unchanged from the node once the transaction is included.
Last updated