[BUG] Gas price validation bypassed when London hardfork is active
- Dominant language
- Go
- Stars
- 164
- Forks
- 213
- Avg merge
- 3d 58m
- Merged PRs (30d)
- 12
Description
## Summary
The EVM module has a critical security vulnerability where **mempool gas price validation is bypassed** when the London hardfork is active, allowing transactions with insufficient fees (below the node's minimum gas price) to be accepted into the mempool.
## Bug Location
**File:** `ante/evm/02_mempool_fee.go`
**Function:** `CheckMempoolFee`
**Line:** 15
```go
func CheckMempoolFee(ctx sdk.Context, fee, mempoolMinGasPrice, gasLimit sdkmath.LegacyDec, isLondon bool) error {
if isLondon {
return nil // BUG: Always bypasses validation when London hardfork is active
}
// ... validation logic never reached when London is active
}
```
## Root Cause
The default chain configuration sets **ALL hardforks to activate at block 0** in `x/vm/types/chain_config.go`:
```go
func DefaultChainConfig(evmChainID uint64) *ChainConfig {
homesteadBlock := sdkmath.ZeroInt() // Block 0
berlinBlock := sdkmath.ZeroInt() // Block 0
londonBlock := sdkmath.ZeroInt() // Block 0
istanbulBlock := sdkmath.ZeroInt() // Block 0
// ... ALL hardforks set to block 0
}
```
This means from genesis block, **ALL hardforks are simultaneously active**:
- `IsHomestead = true`, `IsBerlin = true`, `IsLondon = true`, `IsIstanbul = true`, etc.
Since `IsLondon = true` from block 1 onwards, the validation bypass is always triggered.
## Impact
- **Mempool Security**: Transactions below node's minimum gas price are accepted into mempool
- **Validator Economics**: Nodes cannot enforce their local minimum gas price requirements
- **Network Spam**: Low-cost transactions can flood individual node mempools
- **Fee Market**: Node-level fee filtering is completely bypassed
## Reproduction
1. Configure network with default hardfork settings (London active from genesis)
2. Set node's mempool minimum gas price (e.g., `--minimum-gas-prices="0.000006aatom"`)
3. Send EVM transaction with gas price below the node's minimum
4. Transaction is accepted into mempool despite being below node's threshold
**Example:**
- **Node's Minimum Gas Price**: 0.000006 wei/gas (set via `--minimum-gas-prices`)
- **Transaction Gas Price**: 0.000001 wei/gas (below node's minimum)
- **Expected**: Node rejects transaction (below mempool threshold)
- **Actual**: ✅ Transaction accepted into mempool (validation bypassed)
**Note**: Global network minimum gas price validation still works, but individual node mempool filtering is completely bypassed.
## Evidence
The bug can be confirmed by examining the code flow:
1. **Default hardfork config** sets all hardforks to block 0, making `IsLondon = true`
2. **EVM transactions** go through `mono_decorator.go` → `CheckMempoolFee(..., isLondon=true)`
3. **CheckMempoolFee** immediately returns `nil` when `isLondon=true`
4. **Mempool validation is completely skipped** - no fee checking occurs
This can be verified by adding debug logs to `CheckMempoolFee` which will show the function returning early due to the London bypass.
**Note**: This appears to be an incomplete feature where the London bypass was added as a placeholder but the corresponding EIP-1559 validation logic was never implemented for the EVM transaction path.
## Additional Context
- This appears to be an incomplete feature where London bypass was added as a placeholder for EIP-1559 validation
- Proper EIP-1559 validation exists in `ante/evm/fee_checker.go` for standard Cosmos transactions but not for EVM transactions
- The bug affects any network using default hardfork configuration (common setup)
Contributor guide
Research direction
Start by tracing the EVM transaction path from mono_decorator.go into ante/evm/02_mempool_fee.go, then compare its behavior with the validation in ante/evm/fee_checker.go and the defaults in x/vm/types/chain_config.go. Done means transactions below the node's minimum gas price are rejected from the mempool when London is active, while the reported EIP-1559 behavior remains correct.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, blockchain, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100