eth_getCode returns empty

[wjmelements]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

Daemon:  1.33.0+debug+git.7bdccad+api1.5.0
Local: lotus version 1.33.0+debug+git.7bdccad

Repro Steps

First, deploy a contract with eth_sendRawTransaction. This about 17kb so I don't paste it here, but for my own work I am using Payments.sol.

getcode.json:

    {
        "method": "eth_getCode",
        "params": [
            "0xf6990c51dc94b36c5d5184bf60107efe99dde592",
            "latest"
        ],
        "id": 14,
        "jsonrpc": "2.0"
    }

curl --data @getcode.json -H "Content-Type:application/json" http://localhost:8080/rpc/v1
{"id":14,"jsonrpc":"2.0","result":"0x"}

But the contract is there:

call.json:

    {
        "method": "eth_call",
        "params": [
            {
                "to": "0xf6990c51dc94b36c5d5184bf60107efe99dde592",
                "data": "0x9be5c024"
            },
            "latest"
        ],
        "id": 14,
        "jsonrpc": "2.0"
    }

curl --data @call.json -H "Content-Type:application/json" http://localhost:8080/rpc/v1
{"id":14,"jsonrpc":"2.0","result":"0x00000000000000000000000000000000000000000000000000049e57d6354000"}

Describe the Bug

The contract is deployed with eth_sendRawTransaction. I can interact with it with eth_call, but the code is missing from eth_getCode.

The impact of this is that forge script --fork-url <> can't load existing smart contracts:

    ├─ [0] 0x7392F5951F84C9A8ee8CDC7E2AC9f0445e7A17fb::NETWORK_FEE() [staticcall]
    │   └─ ← [Stop]
    └─ ← [Revert] EvmError: Revert

Logging Information

Not seeing anything noteworthy in the lotus daemon logs. Here are the network logs:

    Host: localhost:1234
    User-Agent: curl/8.7.1
    Accept: */*
    Content-Type: application/json
    Content-Length: 189

    {
        "method": "eth_getCode",
        "params": [
            "0xf6990c51dc94b36c5d5184bf60107efe99dde592",
            "latest"
        ],
        "id": 14,
        "jsonrpc": "2.0"
    }

 << 200 OK 40b
    Date: Thu, 07 Aug 2025 02:00:44 GMT
    Content-Length: 40
    Content-Type: text/plain; charset=utf-8

    {"id":14,"jsonrpc":"2.0","result":"0x"}


[::1]:56810: POST http://localhost:1234/rpc/v1
    Host: localhost:1234
    User-Agent: curl/8.7.1
    Accept: */*
    Content-Type: application/json
    Content-Length: 259

    {
        "method": "eth_call",
        "params": [
            {
                "to": "0xf6990c51dc94b36c5d5184bf60107efe99dde592",
                "data": "0x9be5c024"
            },
            "latest"
        ],
        "id": 14,
        "jsonrpc": "2.0"
    }

 << 200 OK 104b
    Date: Thu, 07 Aug 2025 02:01:11 GMT
    Content-Length: 104
    Content-Type: text/plain; charset=utf-8

    {"id":14,"jsonrpc":"2.0","result":"0x00000000000000000000000000000000000000000000000000049e57d6354000"}

[wjmelements]

The network logs are from mitmdump --mode reverse:http://localhost:1234 --flow-detail 4

[rvagg]

That is pretty odd. For debugging, I'd start here:

lotus/node/impl/eth/lookup.go

Lines 87 to 139 in 190d781

	msg := &types.Message{
	From: builtinactors.SystemActorAddr,
	To: to,
	Value: big.Zero(),
	Method: builtintypes.MethodsEVM.GetBytecode,
	Params: nil,
	GasLimit: buildconstants.BlockGasLimit,
	GasFeeCap: big.Zero(),
	GasPremium: big.Zero(),
	}
	// Try calling until we find a height with no migration.
	var res *api.InvocResult
	for {
	res, err = e.stateManager.Call(ctx, msg, ts)
	if err != stmgr.ErrExpensiveFork {
	break
	}
	ts, err = e.chainStore.GetTipSetFromKey(ctx, ts.Parents())
	if err != nil {
	return nil, xerrors.Errorf("getting parent tipset: %w", err)
	}
	}
	if err != nil {
	return nil, xerrors.Errorf("failed to call GetBytecode: %w", err)
	}
	if res.MsgRct == nil {
	return nil, xerrors.New("no message receipt")
	}
	if res.MsgRct.ExitCode.IsError() {
	return nil, xerrors.Errorf("GetBytecode failed: %s", res.Error)
	}
	var getBytecodeReturn evm.GetBytecodeReturn
	if err := getBytecodeReturn.UnmarshalCBOR(bytes.NewReader(res.MsgRct.Return)); err != nil {
	return nil, xerrors.Errorf("failed to decode EVM bytecode CID: %w", err)
	}
	// The contract has selfdestructed, so the code is "empty".
	if getBytecodeReturn.Cid == nil {
	return nil, nil
	}
	blk, err := e.stateBlockstore.Get(ctx, *getBytecodeReturn.Cid)
	if err != nil {
	return nil, xerrors.Errorf("failed to get EVM bytecode: %w", err)
	}
	return blk.RawData(), nil
	}

- which is doing a GetBytecode call to the EVM builtin actor and expecting to get back a CID which can be loaded from the blockstore which should have the bytes. That call ends up in here: https://github.com/filecoin-project/builtin-actors/blob/8fdbdec5e3f46b60ba0132d90533783a44c5961f/actors/evm/src/lib.rs#L284-L299

The fact that you don't get an error suggests that either getting the zero-length block from the blockstore (unlikely) or you're getting a None which would end you up here:

lotus/node/impl/eth/lookup.go

Lines 128 to 132 in 190d781

	// The contract has selfdestructed, so the code is "empty".
	if getBytecodeReturn.Cid == nil {
	return nil, nil
	}

That would come from this logic: https://github.com/filecoin-project/builtin-actors/blob/8fdbdec5e3f46b60ba0132d90533783a44c5961f/actors/evm/src/lib.rs#L78-L89

[wjmelements]

It fails quietly during LoadActor, probably because this situation can also mean the account is empty.

2025-08-07T14:39:17.520-0500	INFO	node/eth	eth/lookup.go:58	EthGetCode
2025-08-07T14:39:17.520-0500	ERROR	node/eth	eth/lookup.go:79	LoadActorerrresolution lookup failed (t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga): resolve address t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga: actor not found

I have verified that eth_getCode and eth_call are using the same tipset. Next I will compare the stateManager accesses.

[wjmelements]

./lotus state get-actor t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga
Address:	t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga
Balance:	0 FIL
Nonce:		0
Code:		bafk2bzacebmv2k57q5atsj6jdpkyoa2wmap7hj3jmkuzwlycly44cudyfnwyu (fil/15/evm)
Head:		bafy2bzacebuao4ymiexlgxnhvn543fnk7sczp7t6go2q5ed5ct2qxputkafwo
Delegated address:		t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga

[wjmelements]

I think ./lotus state get-actor is succeeding. It does

2025-08-07T17:21:52.027-0500	INFO	statemgr	stmgr/read.go:53	LoadActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacedpcxajkowwzgxptk3auhgped3mlq7btaskvgi6x6bletbdbcxt2k]
2025-08-07T17:21:52.027-0500	INFO	statemgr	stmgr/read.go:58	state.GetActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacedpcxajkowwzgxptk3auhgped3mlq7btaskvgi6x6bletbdbcxt2k]
2025-08-07T17:21:52.027-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01
2025-08-07T17:21:52.027-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01004

whereas EthGetCode does

2025-08-07T17:22:01.860-0500	INFO	statemgr	stmgr/read.go:53	LoadActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzaceavseuuh6w6i2wxzznq2u6t3tu4xqrlr4iujnhdfbi72yxvd4jd4k]
2025-08-07T17:22:01.860-0500	INFO	statemgr	stmgr/read.go:58	state.GetActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzaceavseuuh6w6i2wxzznq2u6t3tu4xqrlr4iujnhdfbi72yxvd4jd4k]
2025-08-07T17:22:01.860-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01
2025-08-07T17:22:01.860-0500	ERROR	node/eth	eth/lookup.go:80	LoadActorerrresolution lookup failed (t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga): resolve address t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga: actor not found

I notice the tipset is different.

[wjmelements]

state.StateGetActor tipset comes from cli.LoadTipSet which seems to load ChainHead.

lookup.EthGetCode tipset comes from GetTipsetByBlockNumberOrHash(ethtypes.NewEthBlockNumberOrHashFromPredefined("latest"))

[rvagg]

In the CLI, most of the commands that address state can take a --tipset flag so you can be specific, but you have to put it in the right place (unfortunately)—just after state but before get-actor. If you follow LoadTipSet calls you'll see it doing optional loading of "tipset" and how it processes it. The key parts are -- either specify the tipset with comma-separated CIDs, or if you're confident the epoch is the stable tipset you care about, provide a number with @X, where X is the height/epoch, and it'll map to tipset for you. @head is the magic form similar to "latest" in Eth land (although to account for deferred execution we subtract one from the actual head when you ask for "latest").

What I'd do next, once I have the actor object at the tipset I care about, is look at the state. We don't have good native CLI tools to inspect state objects because they're different for each actor (although not different enough that we couldn't build nice tools to do this).

So Payments contract (old one) on calibnet at some arbitrary epoch:

lotus state --tipset @2909000 get-actor t410fbzuq2ptawblw2ajvfkydwjmbcxvyjichpmo7v4i
Address:        t410fbzuq2ptawblw2ajvfkydwjmbcxvyjichpmo7v4i
Balance:        0 FIL
Nonce:          0
Code:           bafk2bzaceaauqz2332lqb6cvprlinm4ot4ge4ugkyadgz7qsrukaeyucichlc (fil/17/evm)
Head:           bafy2bzacebyk5hnr3xcwfycaojudnmomfb326nvdanvfiavyjbppb4orkdp3y
Delegated address:              t410fbzuq2ptawblw2ajvfkydwjmbcxvyjichpmo7v4i

Then I can get the state and see what's in it the root by decoding the cbor object and mapping it to what I know about the form that fil/17/evm takes.

$ lotus chain read-obj bafy2bzacebyk5hnr3xcwfycaojudnmomfb326nvdanvfiavyjbppb4orkdp3y | npx cborg hex2diag
86                                                # array(6)
  d8 2a                                           #   tag(42)
    58 27                                         #     bytes(39)
      000155a0e402205a8d7ab04825bfa36985b16d3dda  #       "\x00\x01U\xa0ä\x02 Z\x8dz°H%¿£i\x85±m=Ú"
      9eebbe4abb3f14f9ded22aa5056e2f3104bd        #       "\x9eë¾J»?\x14ùÞÒ*¥\x05n/1\x04½"
  58 20                                           #   bytes(32)
    4b185485827c7a19e134c4c64b15089f45582f919cf8  #     "K\x18T\x85\x82|z\x19á4ÄÆK\x15\x08\x9fEX/\x91\x9cø"
    10abfd24bbf88f41bb10                          #     "\x10«ý$»ø\x8fA»\x10"
  d8 2a                                           #   tag(42)
    58 27                                         #     bytes(39)
      000171a0e40220e30675f45396c3d9e0b3036232ec  #       "\x00\x01q\xa0ä\x02 ã\x06uôS\x96ÃÙà³\x03b2ì"
      c647d1a01e7b9fbfffd042f00ac786733737        #       "ÆGÑ\xa0\x1e{\x9f¿ÿÐBð\x0aÇ\x86s77"
  f6                                              #   null
  01                                              #   uint(1)
  f6                                              #   null

fil/17/evm is actors version 17, evm actor. Unfortunately this is being reported wrong because it's just looking at that code CID and saying that it matches the one it has for v17 but there currently is no network version 17, there's a draft/dev version and it's got an identical set of builtin-actors in the Lotus runtime so if it was more intelligent it should be saying v16 (or we should be forcing a slightly mutated set of actors for the draft/dummy upgrade preparing for v17 ..). But regardless, I shouldn't need to know or care about this because I know my epoch is in this network version, it's not a previous network version actor so I don't actually have to think about this unless I'm close to a network upgrade boundary.

This object is described here:

• https://github.com/filecoin-project/go-state-types/blob/master/builtin/v16/evm/evm_state.go#L34
• https://github.com/filecoin-project/builtin-actors/blob/release/v16/actors/evm/src/state.rs#L115

Whichever takes your fancy, they should match.

These structs are encoded with tuple encoding, so don't expect to see any maps here, we flatten everything to arrays in our cbor encodings on chain.

But the important bit of information I want here is the tombstone field, which is last, and is showing up as f6 (i.e. null) in the cbor, so None in Rust and in the builtin-actor logic that looks at the tombstone. So if I'm debugging this particular issue with the state you have set up, that's the first thing I'm chasing down - does the tombstone have something other than a None? If not, why not?

[wjmelements]

lookup.EthGetCode tipset comes from GetTipsetByBlockNumberOrHash(ethtypes.NewEthBlockNumberOrHashFromPredefined("latest"))

This resolves to tipSetResolver.cs.GetTipSetFromKey(ctx, head.Parents())

(although to account for deferred execution we subtract one from the actual head when you ask for "latest").

This sounds like a problem. Normally if you can get a transaction receipt, the transaction is confirmed and its results would show up in queries of latest. What this bug represents is that when we query latest with eth_call, we get the Ethereum behavior, and perhaps when we query latest with eth_getCode, it might be returning latest - 1. I don't think it should be showing receipts and answering eth_call but withholding code etc.

In particular after I finish running my forge script and I have the receipts from the transactions in that block, when I start another forge script the state from those transactions should be available in latest.

When I was looking into the code today I found that the eth_call route was executing in the ref-fvm while the eth_getCode route was entirely in this repo.

[rvagg]

lotus/node/impl/eth/tipsetresolver.go

Lines 143 to 144 in 190d781

	parent, err := tsr.cs.GetTipSetFromKey(ctx, head.Parents())
	if err != nil {

"latest" points to the tipset of the current chain head's parent tipset. Because the current chain head has the receipts for the parent's messages. We have to perform a unification like this wherever we need to deal with messages and their receipts. Receipts are always in the next tipset. All of the Eth APIs have this kind of thing going on, its intended to be uniform across all of those APIs such that we cleanly map Ethereum view onto Filecoin. There may be edge cases we haven't properly handled, or there may be cases where we have made the wrong choice about how to handle the mapping, but it should be correct with all of the work that's gone in to making it work and validating that against all of the Ethereum tooling that can now view Filecoin as Ethereum-compatible.

[wjmelements]

perhaps when we query latest with eth_getCode, it might be returning latest - 1

I have confirmed this is the issue:
./lotus state get-actor t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga:

2025-08-07T21:31:52.181-0500	INFO	fullnode	full/state.go:482	StateGetActor:tsk={bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq}
2025-08-07T21:31:52.182-0500	INFO	chainstore	store/store.go:1356	cs.GetTipSetFromKey:tsk={bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq}
2025-08-07T21:31:52.182-0500	INFO	statemgr	stmgr/read.go:53	LoadActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq]
2025-08-07T21:31:52.182-0500	INFO	statemgr	stmgr/read.go:58	state.GetActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq]
2025-08-07T21:31:52.182-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01
2025-08-07T21:31:52.182-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01004

./lotus state --tipset @20 get-actor t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga:

2025-08-07T21:31:40.628-0500	INFO	chainstore	store/store.go:1356	cs.GetTipSetFromKey:tsk={}
2025-08-07T21:31:40.628-0500	INFO	fullnode	full/state.go:482	StateGetActor:tsk={bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq}
2025-08-07T21:31:40.628-0500	INFO	chainstore	store/store.go:1356	cs.GetTipSetFromKey:tsk={bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq}
2025-08-07T21:31:40.628-0500	INFO	statemgr	stmgr/read.go:53	LoadActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq]
2025-08-07T21:31:40.628-0500	INFO	statemgr	stmgr/read.go:58	state.GetActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacedl5egllsevftc72r5ziptssp4i5zvqfupxfruyaydbptmyeb3ztq]
2025-08-07T21:31:40.628-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01
2025-08-07T21:31:40.628-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01004

./lotus state --tipset @19 get-actor t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga:

2025-08-07T21:31:31.304-0500	INFO	chainstore	store/store.go:1356	cs.GetTipSetFromKey:tsk={}
2025-08-07T21:31:31.305-0500	INFO	fullnode	full/state.go:482	StateGetActor:tsk={bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega}
2025-08-07T21:31:31.305-0500	INFO	chainstore	store/store.go:1356	cs.GetTipSetFromKey:tsk={bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega}
2025-08-07T21:31:31.305-0500	INFO	statemgr	stmgr/read.go:53	LoadActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega]
2025-08-07T21:31:31.305-0500	INFO	statemgr	stmgr/read.go:58	state.GetActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega]
2025-08-07T21:31:31.305-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01
2025-08-07T21:31:31.305-0500	WARN	rpc	go-jsonrpc@v0.7.0/handler.go:421	error in RPC call to 'Filecoin.StateGetActor': resolution lookup failed (t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga):
    github.com/filecoin-project/lotus/chain/state.(*StateTree).GetActor
        /Users/will/projects/localnet/lotus-local-net/chain/state/statetree.go:374
  - resolve address t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga:
    github.com/filecoin-project/lotus/chain/state.(*StateTree).lookupInternalIDAddress
        /Users/will/projects/localnet/lotus-local-net/chain/state/statetree.go:339
  - actor not found

eth_getCode:

2025-08-07T21:29:33.477-0500	INFO	node/eth	eth/lookup.go:58	EthGetCode
2025-08-07T21:29:33.477-0500	INFO	chainstore	store/store.go:1356	cs.GetTipSetFromKey:tsk={bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega}
2025-08-07T21:29:33.477-0500	INFO	node/eth	eth/lookup.go:70	getCode gotts[bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega]
2025-08-07T21:29:33.477-0500	INFO	statemgr	stmgr/read.go:53	LoadActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega]
2025-08-07T21:29:33.477-0500	INFO	statemgr	stmgr/read.go:58	state.GetActor:addr=t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga,ts=[bafy2bzacech57fy42xbku7irffsz7xhyohvwndbvitfth546f5tubcy563ega]
2025-08-07T21:29:33.477-0500	INFO	statetree	state/statetree.go:123	stateSnaps.getActor:addr=t01
2025-08-07T21:29:33.477-0500	ERROR	node/eth	eth/lookup.go:80	LoadActorerrresolution lookup failed (t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga): resolve address t410f62mqyuo4sszwyxkrqs7waed672m53zmssmf6vga: actor not found

[rvagg]

OK, but an eth_call and an eth_getCode both on "latest" would still be talking to the same tipset; what your above shows is tht the message landed on 19, was executed during 20 which made the state entry, so at the 20 state you should be able to eth_getCode because it exists on chain.

What's the Eth expectation here? That you should be able to land a transaction and get its code in the same block? Can you not just defer by one block after the transaction lands before getting its code or are we after a particular Ethereum style pattern that's not working?