Public /evm RPC returns latest state for unsupported block numbers in eth_call and eth_getCode #158

Activity

1. shyhaeky95 commented on Aug 17, 2026

   

   shyhaeky95

   on Aug 17, 2026

   Author

   More actions

   Following up: the hosted endpoint still reproduces this 1,713,929 blocks later, and there is now a test that reproduces it without depending on state drift. Two of the methods I had listed as untested are also covered below.

   Still reproduces, 1,713,929 blocks later

   Same endpoint, no key. Measured 2026-08-17T03:06:23Z, head 43,391,213 (0x29618ed); eth_chainId 0x3e7, web3_clientVersion hyperliquid evm Mainnet. The original report was at head 41,677,284.

   Controls first, as before — positive eth_getCode(WHYPE, latest) = 2041 bytes; negative eth_getCode(<nonexistent>, latest) = 0x; and a bogus address at 0x1 also returns 0x, so in these eth_getCode calls the address argument is being applied while the block argument is not.

   • Block above head: eth_getCode(WHYPE, 0x32eaf6d) (head + 10,000,000) → no error, 2041 bytes, identical to latest.
   • Same tag twice: eth_call(WHYPE.totalSupply(), 0x286d6ad) read twice → 5787942.346767374 then 5787922.534321297, Δ ≈ −19.81 WHYPE.
   • eth_getBlockByNumber("0x286d6ad", false) still returns that historical block and echoes "number":"0x286d6ad", while the state calls above do not return state corresponding to that tag.

   A deterministic version of test 1

   Test 1 in the original report depends on state changing between two reads, which makes it traffic-dependent. This one does not: a contract cannot have code before the block that created it.

   RPC=https://rpc.hyperliquid.xyz/evm
   C=0x1dd6673260f584f9c2ade5e2ddc5a641fa09b468
   
   # the endpoint itself supplies the deploy block
   curl -s $RPC -H 'content-type: application/json' \
     -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0x91abe23dec9671c4589afb0da994a89dc634475248380d2e808ad38cfbb8a83d"]}'
   # → "contractAddress":"0x1dd6…b468", "blockNumber":"0x27d6651"  (41,772,625)
   
   curl -s $RPC -H 'content-type: application/json' \
     -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["'$C'","0x1"]}'
   # → 212 bytes, identical to latest

   block tag	eth_getCode
   latest	212 bytes
   0x27d6650 (deploy − 1)	212 bytes
   0x1	212 bytes

   A second contract behaves the same — 793 bytes at latest, at deploy − 1 (0x74818c), and at block 1. Its deployment went through a factory, so its receipt carries no contractAddress and the height needs two steps to check:

   # 1) this endpoint places the deploy tx in block 0x74818d (7,635,341)
   curl -s $RPC -H 'content-type: application/json' \
     -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0xf2968212b462a98fe80ad5c7ee9bf91a29e64379b5570d38f0474211be1cd14f"]}'
   # → "blockNumber":"0x74818d", "to":"0x4e59b44847b379578588920ca78fbf26c0b4956c", "contractAddress":null
   
   # 2) the tx → contract link, from an explorer
   # https://api.etherscan.io/v2/api?chainid=999&module=contract&action=getcontractcreation
   #   &contractaddresses=0x393d0b87ed38fc779fd9611144ae649ba6082109
   # → txHash 0xf2968212…, blockNumber 7635341

   That is 2 of 2 contracts I tested, not a survey. For the first contract, the deployment height used here is the one this endpoint returns in its own receipt; for the second it comes from the explorer step above. Both were re-read immediately before posting.

   Two of the methods I had listed as untested

   Same contract, same reasoning. Measured 2026-08-17T03:09:59Z.

   call	latest	0x1	0x27d6650 (deploy − 1)
   eth_getStorageAt(C, 0x0, …)	0x…74a09313a4ce0175fa	same	same
   eth_getTransactionCount(C, …)	0x1	0x1	0x1

   Control: eth_getStorageAt(<nonexistent>, 0x0, latest) returns all zeros, so zero is an answer this endpoint can produce, and the non-zero value at block 1 is not an artifact of the method always returning something.

   eth_getBalance is not decided by this test — the contract holds 0 native at latest, so 0 at block 1 is consistent with either explanation. It would need an address with a non-zero balance and a verified deploy block. I have not run that.

   One note for anyone reproducing test 1

   On a run on 2026-08-12 a 30-second gap did not resolve — both reads returned the same value — while a 90-second gap did. The magnitude and even the presence of a delta depends on wrap/unwrap traffic in the window. The deterministic test above avoids this entirely, and I would suggest it as the reproduction path.

   What would show this is fixed

   Any one of these: eth_getCode or eth_call returning a JSON-RPC error for a non-latest block parameter instead of a result; eth_getCode(<contract>, 0x1) returning 0x for a contract deployed later; or two reads at the same historical tag returning the same value while the value at latest is independently shown to have changed over the same interval.

   I re-ran every check above immediately before posting: the non-latest calls still returned results rather than errors, and the pre-deployment eth_getCode checks still returned the same code as latest. If your result differs, the endpoint, version and configuration you used would be useful to compare against this hosted-RPC measurement.

   Scope

   Unchanged from the original report: this is the hosted https://rpc.hyperliquid.xyz/evm only. I have not run a local hl-node, and I have not tested testnet, so I still cannot say whether this originates in the node implementation or in the hosted RPC layer. No change to the suggested fix.