feat: pushchain/evm v0.2.0 to 0.3.2 upgrade changes

[AryaLanjewar3005]

Summary

cosmos/evm v0.3.2 Upgrade — Full Impact Analysis on push-chain

---

Part 1: Dependency Change — go-ethereum v1.10 → v1.15

The single largest driver of compile-time breakage. The go.mod replace directive was bumped:

# Before
replace github.com/ethereum/go-ethereum => github.com/cosmos/go-ethereum v1.10.26-evmos-rc4.0.20250402013457-cf9d288f0147

# After
replace github.com/ethereum/go-ethereum => github.com/cosmos/go-ethereum v1.15.11-cosmos-0

go-ethereum v1.15 is a major release with five years of breaking changes relative to v1.10. Every item in this section is a direct consequence of that jump.

---

1.1 Missing packages — first failure, most visible

The very first go build ./... after bumping ../evm produced errors like:

github.com/cosmos/evm/precompiles/bank imports
    github.com/ethereum/go-ethereum/core/tracing:
    module replaced by github.com/cosmos/go-ethereum@v1.10.26-evmos-rc4...,
    does not contain package

Same for core/stateless, crypto/kzg4844, consensus/misc/eip1559, trie/utils. These packages were introduced in go-ethereum releases between v1.10 and v1.15. They did not exist in the v1.10 Cosmos fork at all.

Push-chain impact: No push-chain source file directly imported these packages. The failure cascaded from cosmos/evm's own precompiles and internals. The only fix was the go.mod replace bump. Nothing in push-chain source needed to change for this specific issue, but nothing could compile until the replace was updated.

---

1.2 core.Message — from interface to value struct

This is the most pervasive API change in the EVM path.

v1.10 (old):

// Construction
msg := ethtypes.NewMessage(from, to, nonce, value, gasLimit, gasFeeCap, gasTipCap, gasPrice, data, accessList, isFake)

// Field access — all methods
msg.From()
msg.To()
msg.Nonce()
msg.Value()
msg.Gas()
msg.GasPrice()
msg.GasFeeCap()
msg.GasTipCap()
msg.Data()
msg.AccessList()

// Passing to EVM
core.NewEVMTxContext(msg)  // takes interface

v1.15 (new):

// Construction — plain struct literal
msg := core.Message{
    From:             from,
    To:               contract,
    Nonce:            nonce,
    Value:            big.NewInt(0),
    GasLimit:         config.DefaultGasCap,
    GasPrice:         big.NewInt(0),
    GasTipCap:        big.NewInt(0),
    GasFeeCap:        big.NewInt(0),
    Data:             data,
    AccessList:       ethtypes.AccessList{},
    SkipNonceChecks:  true,
    SkipFromEOACheck: true,
}

// Field access — direct struct fields
msg.From
msg.To
msg.Nonce
msg.Value
msg.GasLimit
msg.GasPrice
msg.GasFeeCap
msg.GasTipCap
msg.Data
msg.AccessList

// Passing to EVM
core.NewEVMTxContext(&msg)  // takes pointer to struct

Push-chain files affected:

• x/uexecutor/keeper/evm.go — every CallEVM helper that built a message: CallFactoryToGetUEAAddressForOrigin, CallFactoryGetOriginForUEA, GetUniversalCoreQuoterAddress, GetUniversalCoreWPCAddress, GetDefaultFeeTierForToken, GetSwapQuote, CallUEADomainSeparator, GetGasPriceByChain, GetL1GasFeeByChain, GetTssFundMigrationGasLimitByChain — approximately 10 call sites
• x/uexecutor/keeper/deploy_uea.go — UEA deploy message construction
• x/uexecutor/types/expected_keepers.go — interface signatures referencing core.Message
• x/uexecutor/mocks/mock_evmkeeper.go — mock method signatures
• test/integration/uexecutor/evm_hooks_and_outbound_test.go — five call sites passed nil as the core.Message argument to PostTxProcessing(ctx, sender, nil, receipt). In v1.10, nil was valid because the message was an interface (nullable). In v1.15, core.Message is a concrete value type — nil is not assignable, causing a compile error cannot use nil as core.Message value. Fixed by replacing all five nils with core.Message{} (the zero value).

---

1.3 statedb.Account.Balance — *big.Int → *uint256.Int

v1.10: Balance *big.Int

v1.15: Balance *uint256.Int — go-ethereum switched its internal balance representation to the EVM's native 256-bit integer type throughout the state layer.

Push-chain files affected:

• x/uregistry/keeper/genesis.go — deployImplementationContract, deployProxyAdminContract, deployProxyContract all set Balance: big.NewInt(0). Changed to Balance: new(uint256.Int).

The change is subtle but causes a compile error because *big.Int and *uint256.Int are distinct types with no implicit conversion.

---

1.4 vm.Contract.Caller() — field removed, method added

v1.10: contract.CallerAddress was a public common.Address field on vm.Contract.

v1.15: The field was removed and replaced with a Caller() method.

Push-chain files affected:

• utils/precompile/exec.go — reads the caller address when dispatching a precompile call. Changed contract.CallerAddress → contract.Caller().

---

1.5 BlockContext.Time — *big.Int → uint64

v1.10: vm.BlockContext{ Time: big.NewInt(ctx.BlockTime().Unix()), ... }

v1.15: vm.BlockContext{ Time: uint64(ctx.BlockTime().Unix()), ... } — go-ethereum simplified time representation to a plain uint64 (UNIX seconds) across the entire EVM.

Push-chain files affected: Any keeper code that constructed vm.BlockContext directly. In push-chain, this flows through x/vm/keeper/state_transition.go in ../evm, which push-chain delegates to — but any custom BlockContext construction in hooks or custom message handling had to be updated.

---

1.6 vm.EVMLogger → tracing.Hooks

v1.10: Tracers passed to the EVM implemented the vm.EVMLogger interface.

v1.15: The tracer system was redesigned. Tracers are now *tracing.Hooks structs from the new core/tracing package.

Push-chain files affected: Any code passing a tracer to ApplyMessage or constructing an EVM with a custom logger. Push-chain primarily passes nil for the tracer, so the impact was limited to updating the type annotations in interfaces.

---

1.7 ethtypes.LogsBloom → ethtypes.CreateBloom

v1.10: ethtypes.LogsBloom(logs) returned a bloom filter directly.

v1.15: ethtypes.CreateBloom(&ethtypes.Receipt{Logs: logs}).Bytes() — the function was refactored and the old form removed.

Push-chain files affected:

• x/uexecutor/keeper/evm_hooks.go — computes bloom filters for EVM transaction logs.

---

Part 2: cosmos/evm Internal API Changes

Changes in ../evm itself (not go-ethereum) that broke push-chain's integration layer.

---

2.1 ApplyMessage and ApplyMessageWithConfig gained an internal bool parameter

v0.3.1:

res, err := k.ApplyMessage(ctx, msg, tracer, commit)
res, err := k.ApplyMessageWithConfig(ctx, msg, tracer, commit, cfg, txConfig)

v0.3.2:

res, err := k.ApplyMessage(ctx, msg, tracer, commit, true)
res, err := k.ApplyMessageWithConfig(ctx, msg, tracer, commit, cfg, txConfig, true)

The internal flag tells the EVM executor whether the call is an internally-triggered call (from cosmos modules) vs a user-submitted EVM transaction. This distinction drives different gas accounting and receipt generation paths introduced in the same upgrade.

Push-chain files affected:

• x/uexecutor/keeper/evm.go — all CallEVM helpers that ultimately call ApplyMessage
• x/uexecutor/types/expected_keepers.go — the EVMKeeper interface definition
• x/uexecutor/mocks/mock_evmkeeper.go — mock method signatures

---

2.2 EVM keeper constructor changed — evmkeeper.NewKeeper

NewKeeper in v0.3.2 gained additional parameters for the new derived-tx and gas accounting infrastructure.

Push-chain files affected:

• app/app.go — the keeper instantiation call had to be updated with the new parameter set.

---

2.3 vm.NewAppModule — module constructor changed

Same pattern: NewAppModule gained parameters.

Push-chain files affected:

• app/app.go — module registration in the module manager.

---

2.4 AccountKeeper interface grew three unordered-transaction methods

v0.3.2 cosmos/evm's ante package introduced support for unordered transactions. The AccountKeeper interface in github.com/cosmos/evm/ante/interfaces now requires:

type AccountKeeper interface {
    // ... existing methods ...
    UnorderedTransactionsEnabled() bool
    RemoveExpiredUnorderedNonces(ctx sdk.Context) error
    TryAddUnorderedNonce(ctx sdk.Context, sender []byte, timeout time.Time) error
}

cosmos-sdk v0.50's AccountKeeper does not implement these methods. Push-chain is on cosmos-sdk v0.50 and does not use unordered transactions.

Push-chain files affected:

• app/ante/ante_evm.go — introduced evmAccountKeeperWrapper:

type evmAccountKeeperWrapper struct {
    AccountKeeper
}

var _ anteinterfaces.AccountKeeper = evmAccountKeeperWrapper{}

func (w evmAccountKeeperWrapper) UnorderedTransactionsEnabled() bool { return false }
func (w evmAccountKeeperWrapper) RemoveExpiredUnorderedNonces(_ sdk.Context) error { return nil }
func (w evmAccountKeeperWrapper) TryAddUnorderedNonce(_ sdk.Context, _ []byte, _ time.Time) error {
    return nil
}

This adapter wraps push-chain's existing AccountKeeper and provides safe no-op stubs. Without it the ante handler fails to compile because the type assertion fails.

---

2.5 Precompile constructors added required parameters

v0.3.2 expanded the precompile constructors to support richer functionality:

Precompile	New required parameter	Reason
bankprecompile.NewPrecompile	BankKeeper (first arg)	Direct bank queries in bank precompile
govprecompile.NewPrecompile	appCodec codec.Codec	Codec-aware governance proposal handling
slashingprecompile.NewPrecompile	BankKeeper	Bank queries for slashing rewards
evidenceprecompile.NewPrecompile	BankKeeper	Bank queries for evidence rewards

Push-chain files affected:

• app/precompiles.go — NewAvailableStaticPrecompiles function signature and all four call sites. The function also had to add appCodec codec.Codec to its own parameter list.

---

2.6 GetChainID() → GetEIP155ChainID().Uint64()

v0.3.1: k.GetChainID() returned uint64 directly.

v0.3.2: k.GetEIP155ChainID() returns *big.Int (mirroring go-ethereum's representation of chain IDs). Callers must call .Uint64() to get a scalar value.

Push-chain files affected: Any keeper code that called GetChainID() to embed the chain ID into an EVM message. Changed to k.GetEIP155ChainID().Uint64().

---

2.7 Bech32StringFromHexAddress replaces EthHexToCosmosAddr

v0.3.1: EthHexToCosmosAddr(hexAddr string) sdk.AccAddress

v0.3.2: Bech32StringFromHexAddress(hexAddr string) string — renamed and changed return type from sdk.AccAddress to string.

Push-chain files affected:

• app/app.go and address conversion utilities.

---

2.8 EVMChainID type: string → uint64

v0.3.1: DefaultChainConfig(chainID string) — chain ID as a string like "9000".

v0.3.2: DefaultChainConfig(evmChainID uint64) — chain ID as a typed integer. The internal testChainID = 262144 constant was also introduced as the fallback when evmChainID == 0.

Push-chain files affected:

• app/config.go — EVMAppOptions now calls evmtypes.DefaultChainConfig(EVMChainID) where EVMChainID = uint64(9000) is declared in app/app.go.

---

2.9 MakeConfig now takes evmChainID uint64

The encoding config constructor gained evmChainID uint64 to properly configure EIP-712 typed data signing with the correct chain ID.

Push-chain files affected:

• app/app.go — cosmosevmencoding.MakeConfig(EVMChainID).

---

2.10 EthMsgsFromTendermintBlock return arity changed

v0.3.1: msgs, err := b.EthMsgsFromTendermintBlock(resBlock, blockRes) — 2 return values

v0.3.2: msgs, _, err := b.EthMsgsFromTendermintBlock(resBlock, blockRes) — 3 return values (added metadata return)

Push-chain files affected: Any code calling this RPC backend method.

---

2.11 GetTxByEthHash return arity changed

v0.3.1: res, err := b.GetTxByEthHash(hash) — 2 return values

v0.3.2: res, additional, err := b.GetTxByEthHash(hash) — 3 return values (added *rpctypes.TxResultAdditionalFields for derived-tx metadata)

Push-chain files affected: Any code calling this directly.

---

2.12 ShanghaiBlock / CancunBlock → ShanghaiTime / CancunTime + new PragueTime

v0.3.1: Hardfork activation was block-number based: ShanghaiBlock, CancunBlock.

v0.3.2: Activation is timestamp-based (matching mainnet Ethereum): ShanghaiTime, CancunTime, and a new PragueTime. This is a foundational shift in how EVM hardfork progression works.

Push-chain files affected: The DefaultChainConfig in ../evm/x/vm/types/chain_config.go handles this internally. Push-chain source files are largely shielded unless they constructed custom chain configs directly.

---

Part 3: Runtime Behavioral Regressions Introduced by v0.3.2

These are not compile errors. They are behavioral changes that only manifest at runtime, making them harder to detect.

---

3.1 CallEVMWithData — Gas Meter Overflow on Revert

Severity: CRITICAL — Runtime panic, all internal EVM calls with infinite gas meter affected

File: ../evm/x/vm/keeper/call_evm.go

Upstream commits: 72b035b ("Consume gas when EVM is called internally"), d1a82a7 ("gas optimizations")

What changed in v0.3.2

The CallEVMWithData function — which push-chain uses for all internal EVM calls via CallEVM — was changed to charge gas against the cosmos gas meter:

// v0.3.1 — no cosmos gas meter interaction
res, err := k.ApplyMessage(ctx, msg, nil, commit)
if err != nil { return nil, err }
if res.Failed() {
    return res, errorsmod.Wrap(types.ErrVMExecution, res.VmError)
}
return res, nil

// v0.3.2 — cosmos gas meter mutated
res, err := k.ApplyMessage(ctx, msg, nil, commit, true)
if err != nil { return nil, err }
if res.Failed() {
    k.ResetGasMeterAndConsumeGas(ctx, ctx.GasMeter().Limit())  // revert: burn all gas
    return res, errorsmod.Wrap(types.ErrVMExecution, res.VmError)
}
ctx.GasMeter().ConsumeGas(res.GasUsed, "apply evm message")    // success: charge actual gas
return res, nil

The intent was sound for the nominal case: EVM gas cost should be visible in the cosmos receipt. But the revert path calls ResetGasMeterAndConsumeGas(ctx, ctx.GasMeter().Limit()) to implement EVM-standard "a reverting tx burns all gas."

How push-chain is affected

Push-chain calls CallEVM (→ CallEVMWithData) from multiple cosmos message handlers:

• ExecuteInboundGas, ExecuteInboundFundsAndPayload, ExecutePayload in x/uexecutor/keeper/
• Read-only probes that legitimately revert: GetSwapQuote, GetGasPriceByChain, GetL1GasFeeByChain, GetTssFundMigrationGasLimitByChain

These handlers run under the standard cosmos ante handler which provides an infinite gas meter. An infinite gas meter's .Limit() returns math.MaxUint64.

When GetSwapQuote is called and the quoter contract reverts (expected behaviour when no AMM pool exists, e.g. in tests), the code calls:

k.ResetGasMeterAndConsumeGas(ctx, math.MaxUint64)

This sets the gas consumed counter to MaxUint64. The very next ConsumeGas call in any downstream code path (e.g., UpdateUniversalTx in execute_inbound_gas.go) triggers:

panic: types.ErrorGasOverflow{Descriptor:"apply evm message"}

Test that caught it: TestInboundGas/quorum_reached_moves_GAS_inbound_out_of_pending_state

Why DerivedEVMCallWithData was not affected: The sibling function already used ctx.CacheContext(), isolating execution from the parent gas meter. CallEVMWithData was not given the same treatment in the upstream refactor.

Fix applied (with approval)

Wrapped CallEVMWithData body in ctx.CacheContext(), mirroring DerivedEVMCallWithData:

// After fix
tmpCtx, commitState := ctx.CacheContext()
res, err := k.ApplyMessage(tmpCtx, msg, nil, commit, true)
if err != nil { return nil, err }
if res.Failed() {
    // tmpCtx discarded, parent meter untouched — no overflow possible
    return res, errorsmod.Wrap(types.ErrVMExecution, res.VmError)
}
commitState()
ctx.GasMeter().ConsumeGas(res.GasUsed, "apply evm message")  // only actual gas charged
return res, nil

On the success path, this preserves upstream intent: charge the parent meter the actual gas used. On the revert path, the cache is discarded and the parent meter is never touched — eliminating the overflow entirely.

---

3.2 GetTransactionReceipt — Returns Error Instead of Null for Pending Transactions

Severity: CRITICAL — All Ethereum clients (forge, cast, ethers.js) abort receipt polling on every broadcast

File: ../evm/rpc/backend/tx_info.go

Upstream commit: eee08ea (0.3.2 version merge)

What changed in v0.3.2

// v0.3.1
res, err := b.GetTxByEthHash(hash)
if err != nil {
    b.logger.Debug("tx not found", "hash", hexTx, "error", err.Error())
    return nil, nil   // null result, no error — Ethereum standard for pending txs
}

// v0.3.2
res, additional, err := b.GetTxByEthHash(hash)
if err != nil {
    b.logger.Debug("tx not found", "hash", hexTx, "error", err.Error())
    return nil, err   // propagates error as JSON-RPC -32000
}

What the Ethereum standard requires

eth_getTransactionReceipt must return null (not an error) when the transaction has not yet been mined. This is the signal clients use to distinguish "pending, keep polling" from "genuine server error." Returning a -32000 error is interpreted by all Ethereum tooling (forge, cast, ethers.js, viem) as a permanent failure.

How push-chain is affected

The e2e-tests/setup.sh all command deploys push-chain's core contracts using forge script ... --broadcast --slow. With v0.3.2:

1. Forge broadcasts a transaction → gets a tx hash
2. Forge calls eth_getTransactionReceipt(hash) to wait for confirmation
3. The tx is in the mempool or just committed to a block but the CometBFT indexer hasn't responded yet
4. GetTxByEthHash returns "ethereum tx not found" → GetTransactionReceipt returns nil, err
5. The JSON-RPC server sends: {"error": {"code": -32000, "message": "GetTxByEthHash 0x...: ethereum tx not found"}}
6. Forge interprets this as a permanent failure (not "pending, keep polling")
7. After 3 retries, forge gives up and the setup script calls --resume
8. This loops 29+ times — each tx lands on-chain, but forge can never confirm it

The tx IS on-chain and findable — manually calling eth_getTransactionReceipt after the fact returns a valid receipt with status: 0x1. The failure is entirely due to the timing window between broadcast and CometBFT indexer availability (typically under 1 second), which was previously handled gracefully by return nil, nil.

Fix applied (with approval)

res, additional, err := b.GetTxByEthHash(hash)
if err != nil {
    b.logger.Debug("tx not found", "hash", hexTx, "error", err.Error())
    return nil, nil   // restored: null for not-found, clients keep polling
}

The other return nil, err lines introduced by the same merge commit (for block-not-found, block-result-not-found, and decode failures) were left intact — those are genuine server errors that should propagate.

---

Part 4: Genesis and Node Configuration Changes

These changes do not affect push-chain's Go source. They affect how the local devnet is initialized and how the node's JSON-RPC server is configured.

---

4.1 chain_config removed from types.Params genesis

Severity: HIGH — Node startup panic, devnet cannot start

File: local-native/scripts/setup-genesis-auto.sh

What changed in v0.3.2

In v0.3.1, the EVM chain configuration (chain ID, hardfork block numbers, etc.) was part of types.Params and persisted in genesis:

{
  "app_state": {
    "evm": {
      "params": {
        "evm_denom": "upc",
        "chain_config": {
          "chain_id": 9000,
          "homestead_block": "0"
        }
      }
    }
  }
}

In v0.3.2, chain_config was removed from the Params proto definition entirely. Chain configuration is now registered once at process startup via EVMConfigurator in app/config.go and is never stored in genesis or on-chain state. This matches the upstream direction of making chain config a build-time constant rather than a governance-managed parameter.

How push-chain devnet was affected

setup-genesis-auto.sh was still injecting:

update_genesis ".app_state[\"evm\"][\"params\"][\"chain_config\"][\"chain_id\"]=$EVM_CHAIN_ID"

pchaind uses strict proto-JSON unmarshaling when loading genesis. Unknown fields cause a panic, not a warning:

panic: unknown field "chain_config" in types.Params

The node process exited immediately on every start attempt. The devnet could never reach consensus because validator 1 (the genesis validator) died before producing a single block.

Fix

Removed that line from the setup script. chain_config is now set entirely via EVMAppOptions → EVMConfigurator at startup, requiring no genesis entry.

---

4.2 evm-chain-id in app.toml is now the authoritative EVM chain ID for the RPC backend

Severity: HIGH — All forge and cast transactions rejected at submission

File: local-native/scripts/setup-genesis-auto.sh

What changed in v0.3.2

Previously, the EVM chain ID used by the JSON-RPC backend for transaction validation was derived from the genesis params (via chain_config.chain_id). In v0.3.2, with chain_config removed from genesis, the RPC backend reads the EVM chain ID from app.toml:

# app.toml — generated by pchaind init
[evm]
evm-chain-id = 262144   # DefaultEVMChainID from ../evm/server/config/config.go

The default value 262144 is the internal test chain ID (testChainID in chain_config.go). This default exists so the evm module works out of the box in test environments. It has no relation to push-chain's production chain ID of 9000.

How push-chain devnet was affected

The devnet setup script ran pchaind init which generated app.toml with evm-chain-id = 262144. The script never patched this field. The running node then had a split personality:

• eth_chainId JSON-RPC returned 0x2328 (= 9000) — correct, read from EVMConfigurator
• SendRawTransaction validated against b.chainID = 262144 — wrong, read from app.toml

When forge signed and submitted a transaction with chain ID 9000 (derived from eth_chainId), the RPC backend's SendRawTransaction rejected it:

error code -32000: incorrect chain-id; expected 262144, got 9000

This happened before any tx ever reached the mempool. Every forge deployment command failed at submission, not at confirmation.

Fix

Added to setup-genesis-auto.sh immediately after pchaind init:

sed -i.bak "s/evm-chain-id = [0-9]*/evm-chain-id = ${EVM_CHAIN_ID}/g" "$HOME_DIR/config/app.toml"

EVM_CHAIN_ID="9000" is already defined in local-native/env.sh. The patch writes it into app.toml so the RPC backend's chain ID matches EVMConfigurator's chain ID.

---

Summary Table

#	Category	Change	Push-chain symptom	Fix location
1.1	go-eth v1.15	New packages missing in v1.10 fork	go build fails immediately	go.mod replace bump
1.2	go-eth v1.15	core.Message value struct	Compile errors in all EVM call sites; nil invalid in tests	x/uexecutor/keeper/*.go, test file
1.3	go-eth v1.15	Balance: *uint256.Int	Compile error in genesis deployment	x/uregistry/keeper/genesis.go
1.4	go-eth v1.15	contract.Caller() method	Compile error in precompile exec	utils/precompile/exec.go
1.5	go-eth v1.15	BlockContext.Time: uint64	Compile error in EVM context construction	push-chain keeper files
1.6	go-eth v1.15	tracing.Hooks replaces vm.EVMLogger	Compile errors in tracer usage	push-chain ante/hook files
1.7	go-eth v1.15	ethtypes.CreateBloom replaces LogsBloom	Compile error in bloom filter computation	x/uexecutor/keeper/evm_hooks.go
2.1	cosmos/evm	ApplyMessage +internal bool	Compile errors at all apply sites	x/uexecutor/keeper/*.go, interfaces, mocks
2.2	cosmos/evm	NewKeeper params changed	Compile error in app wiring	app/app.go
2.3	cosmos/evm	NewAppModule params changed	Compile error in module registration	app/app.go
2.4	cosmos/evm	AccountKeeper 3 new methods	Compile error: interface not satisfied	app/ante/ante_evm.go (new wrapper)
2.5	cosmos/evm	Precompile constructors +params	Compile errors in precompile init	app/precompiles.go
2.6	cosmos/evm	GetEIP155ChainID().Uint64()	Compile error at chain ID fetch sites	push-chain keeper
2.7	cosmos/evm	Bech32StringFromHexAddress renamed	Compile error in address conversion	app/app.go
2.8	cosmos/evm	DefaultChainConfig(uint64)	Type mismatch in config	app/config.go
2.9	cosmos/evm	MakeConfig(evmChainID uint64)	Compile error in encoding setup	app/app.go
2.10	cosmos/evm	EthMsgsFromTendermintBlock 3 returns	Compile error at call site	RPC/hook files
2.11	cosmos/evm	GetTxByEthHash 3 returns	Compile error at call site	RPC/backend files
2.12	cosmos/evm	Timestamp-based hardforks	Config restructuring	Handled inside ../evm
3.1	cosmos/evm	CallEVMWithData gas meter overflow	Runtime panic on any reverting internal EVM call with infinite gas meter	../evm/x/vm/keeper/call_evm.go
3.2	cosmos/evm	GetTransactionReceipt error vs null	Forge/cast abort on every tx, e2e setup loops 29+ times	../evm/rpc/backend/tx_info.go
4.1	Genesis config	chain_config removed from Params	Node startup panic — unknown field in proto unmarshal	local-native/scripts/setup-genesis-auto.sh
4.2	Node config	evm-chain-id in app.toml is authoritative	All forge txs rejected — chain ID mismatch (262144 vs 9000)	local-native/scripts/setup-genesis-auto.sh

References

• Fixes #
• Related issue/PR:

Changes

Testing

• go test ./...

Checklist

• Ready for review
• Docs updated (if applicable)
• Env vars updated (if applicable)