blockHash is 0x000000... instead of null for pending transaction

According to the json-rpc doc for eth_getTransactionByHash:

blockHash : DATA , 32 Bytes - hash of the block where this transaction was in. null when its pending.

However the response I got from infura is something like:

    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "blockNumber": null,
        "from": "0xcb1746792ec16a8deadbff95c2df99f47a8d759f",
        "gas": "0xcb20",
        "gasPrice": "0x98bca5a00",
        "hash": "0x6e70bab11ee74fdbf05ffdc79aa4fa4be0b30418944ae6720d978c732d76edcb",
        "input": "0x",
        "nonce": "0xe0",
        "r": "0x4abb60f4e816cede8563d5e84b5f8e8b276b100507906c4be828c2fa741d489f",
        "s": "0x38c15efe8fb0955531cf8fb8a6080f64d93534c5b1ff439ef07cc8118196450a",
        "to": "0xcb1746792ec16a8deadbff95c2df99f47a8d759f",
        "transactionIndex": "0x0",
        "v": "0x1b",
        "value": "0x0"

(I’m currently working on ropsten if that matters)

I know I could check if blockNumber is null instead or check if blockHash is 0, but still it’ll be nice if this could be fixed.


I verified that this is actually the behavior of the underlaying geth nodes. I agree it’s not ideal and seems to differ from the spec, but we have to make sure that by changing the behavior to the correct response we don’t inadvertently break other users who are now expecting a 0-values hash instead of null.

So, we have a couple options:

  • Update our docs to the current behavior (and notify the geth team that their docs at are incorrect as well)
  • Update our client to implement the correct behavior (filter out the 0-valued blockHash when blockNumber is null)
  • Try to get the correct behavior in geth (and potentially other ethereum clients) fixed upstream.

We’ll need to think a bit about which is the best path forward, thanks for bringing it to our attention!