Inconsistent handling of unprotected transactions (Geth vs. Cosmos/EVM)

[zsystm]

1. Background

In Ethereum, legacy (pre-EIP-155) transactions—those signed without a chain ID and using v = 27/28—are still considered valid by execution clients such as Geth if included in a block, regardless of local RPC or mempool policies.

In contrast, Cosmos/EVM currently gates acceptance of such transactions at the consensus level via the evmParams.allow_unprotected_txs parameter.

• If false (the default), all legacy transactions are rejected even if included in a block.
• If true, legacy transactions are allowed, but majority of nodes must agree via governance to enable them.

This creates rigidity, incompatibility with tooling, and unnecessary governance churn for what should be a local policy decision.

2. Problem Statement

1. Overly rigid consensus logic
   Geth gives operators freedom via the --rpc.allow-unprotected-txs flag. Cosmos/EVM hardcodes this at the consensus layer.

2. Deviation from EVM client behavior
   Other EVMs accept legacy txs in consensus while optionally filtering them from mempool/RPC. Cosmos/EVM fails txs at the ante level unless globally permitted.

3. Proposed Solution

Remove allow_unprotected_txs from EVM params and refactor the antehandler logic accordingly.

Accept transactions regardless of EIP-155 chain ID, as long as they are validly signed — that is:

• v = 27/28 (unprotected tx) or
• v = 35/36/... (EIP-155 protected tx with chain ID matching ChainConfig.ChainID)

[linear]

EVM-187 Inconsistent handling of unprotected transactions (Geth vs. Cosmos/EVM)