Please debug and fix the following issue:

Problem Description

Issue #553: core/txpool: Include operator fee in sufficient fund checks

Problem Description

The transaction pool currently doesn't include operator fees when checking for sufficient funds. While this isn't consensus-critical, it creates a poor user experience because transactions without enough balance to cover operator fees are accepted into the pool and later fail on execution. This leads to confusion and delays for users who expect immediate feedback when submitting transactions.

The validation logic in the legacy pool's transaction list must ensure that accounts have enough balance to cover both the transaction value and all applicable rollup-related fees (including operator fees and L1 rollup costs) before the transaction is accepted into the pool.

Function References

• NewTotalRollupCostFunc, ExtractOperatorFeeParams, and ExtractEcotoneFeeParams already exist in the codebase and should be used or updated as needed.
  • NewTotalRollupCostFunc determines how rollup cost components (L1 and operator) are combined based on the current network upgrade state.
  • ExtractOperatorFeeParams retrieves operator fee constants and scalars from fee configuration parameters.
  • ExtractEcotoneFeeParams extracts the L1-related fee parameters (such as base fee scalar and blob base fee scalar).

Isthmus Activation Time

"Isthmus activation time" refers to the network upgrade timestamp at which new rollup fee behavior (including operator rollup cost) becomes active.
It can be accessed through the chain configuration (e.g., via chain.Config().IsthmusTime) or similar network upgrade checks.
Before this activation time, only L1 rollup cost is included; after it, both L1 and operator rollup costs apply.

Implementation Target

The new sufficient-fund validation logic should be added to: core/txpool/legacypool/list.go:list.Add

Task

Your Task

Issue Description:

Issue #553: core/txpool: Include operator fee in sufficient fund checks

Problem Description

The transaction pool currently doesn't include operator fees when checking for sufficient funds. While this isn't consensus-critical, it creates a poor user experience because transactions without enough balance to cover operator fees are accepted into the pool and later fail on execution. This leads to confusion and delays for users who expect immediate feedback when submitting transactions.

The validation logic in the legacy pool's transaction list must ensure that accounts have enough balance to cover both the transaction value and all applicable rollup-related fees (including operator fees and L1 rollup costs) before the transaction is accepted into the pool.

Function References

• NewTotalRollupCostFunc, ExtractOperatorFeeParams, and ExtractEcotoneFeeParams already exist in the codebase and should be used or updated as needed.
  • NewTotalRollupCostFunc determines how rollup cost components (L1 and operator) are combined based on the current network upgrade state.
  • ExtractOperatorFeeParams retrieves operator fee constants and scalars from fee configuration parameters.
  • ExtractEcotoneFeeParams extracts the L1-related fee parameters (such as base fee scalar and blob base fee scalar).

Isthmus Activation Time

"Isthmus activation time" refers to the network upgrade timestamp at which new rollup fee behavior (including operator rollup cost) becomes active.
It can be accessed through the chain configuration (e.g., via chain.Config().IsthmusTime) or similar network upgrade checks.
Before this activation time, only L1 rollup cost is included; after it, both L1 and operator rollup costs apply.

Implementation Target

The new sufficient-fund validation logic should be added to: core/txpool/legacypool/list.go:list.Add

Available Tools

This is an observability task - you MUST use observability tools (Loki, Grafana) to debug and understand the issue.

You have access to observability data and collaboration tools that may help you solve this issue.

CRITICAL: Do NOT add 2>/dev/null or 2>&1 /dev/null to MCP commands! You need to see error messages to debug issues. If a command fails silently, you cannot diagnose the problem.

Loki (Log Aggregation)

Query logs using MCP (primary method):

# USE MCP (via Grafana)
{{
  echo '{{"jsonrpc":"2.0","id":1,"method":"initialize","params":{{"protocolVersion":"2024-11-05","clientInfo":{{"name":"agent","version":"1.0"}},"capabilities":{{}}}}}}';
  echo '{{"jsonrpc":"2.0","method":"notifications/initialized","params":{{}}}}';
  echo '{{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{{"name":"query_loki","arguments":{{"query":"{{job=\"ethereum-optimism-op-geth-553-558-observability\"}}","start":"now-30d","limit":100}}}}}}';
}} | mcp-loki

# Direct API fallback (if MCP fails)
curl -sG "http://loki:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={{job="ethereum-optimism-op-geth-553-558-observability"}}' \
  --data-urlencode 'limit=100' | jq '.data.result[].values[][1]'

IMPORTANT: Use the job label to query logs:

• {{job="ethereum-optimism-op-geth-553-558-observability"}} - All logs from this task
• {{job="ethereum-optimism-op-geth-553-558-observability",service="app"}} - Application logs
• {{job="ethereum-optimism-op-geth-553-558-observability"}} |= "ERROR" - Filter for ERROR messages
• {{job="ethereum-optimism-op-geth-553-558-observability"}} |~ "keyword1|keyword2" - Search with regex

Available labels: job, service, service_name, level, source

Plane (Project Management)

Look up related issues and PRs using the mcp-plane wrapper:

# List projects
{{
  echo '{{"jsonrpc":"2.0","id":1,"method":"initialize","params":{{"protocolVersion":"2024-11-05","clientInfo":{{"name":"agent","version":"1.0"}},"capabilities":{{}}}}}}';
  echo '{{"jsonrpc":"2.0","method":"notifications/initialized","params":{{}}}}';
  echo '{{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{{"name":"get_projects","arguments":{{}}}}}}';
}} | mcp-plane

Available tools: get_projects, get_issue_using_readable_identifier, get_issue_comments, create_issue, update_issue See /app/mcp-servers/plane/README.md for full documentation.

Mattermost (Team Communication)

Search team discussions using the mcp-mattermost wrapper:

# List channels
{{
  echo '{{"jsonrpc":"2.0","id":1,"method":"initialize","params":{{"protocolVersion":"2024-11-05","clientInfo":{{"name":"agent","version":"1.0"}},"capabilities":{{}}}}}}';
  echo '{{"jsonrpc":"2.0","method":"notifications/initialized","params":{{}}}}';
  echo '{{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{{"name":"mattermost_channels","arguments":{{}}}}}}';
}} | mcp-mattermost

# Search for messages about a topic
{{
  echo '{{"jsonrpc":"2.0","id":1,"method":"initialize","params":{{"protocolVersion":"2024-11-05","clientInfo":{{"name":"agent","version":"1.0"}},"capabilities":{{}}}}}}';
  echo '{{"jsonrpc":"2.0","method":"notifications/initialized","params":{{}}}}';
  echo '{{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{{"name":"mattermost_search","arguments":{{"query":"error bug","limit":20}}}}}}';
}} | mcp-mattermost

Available tools: mattermost_channels, mattermost_fetch, mattermost_search See /app/mcp-servers/mattermost/README.md for full documentation.

Notes

• MCP Config: /config/mcp-config.txt - Source this file to get API keys and tokens
• MCP Server Docs: /app/mcp-servers/*/README.md - Full documentation for each MCP server
• Working directory: /app/repo (source code location)
• REQUIREMENTS: You MUST demonstrate use of observability tools (Loki, Mattermost, or Plane) in your debugging process

Requirements

1. The transaction pool must reject transactions with ErrInsufficientFunds when the account balance is insufficient to cover the sum of gas limit cost, transaction value, and L1 rollup cost (calculated from L1 fee parameters).
2. The transaction pool must reject transactions with ErrInsufficientFunds when the account balance is insufficient to cover the sum of gas limit cost, transaction value, and operator rollup cost (calculated from operator fee parameters).
3. The transaction pool pending list must track and maintain a total cost value for each transaction that includes both the base transaction cost (gas limit × gas price + value) and any applicable rollup costs (L1 cost and/or operator cost).
4. When a transaction is replaced with a higher gas price transaction, the transaction pool must update the total pending cost correctly by recalculating rollup costs for the replacement transaction and adjusting the tracked total accordingly.
5. When underlying rollup cost parameters change (such as an increase in the operator fee constant), the transaction pool must recalculate rollup costs for pending transactions and reject any transactions that become underfunded, reporting the exact amount of missing funds in the ErrInsufficientFunds error.
6. When sufficient balance is added to an account after rollup cost parameter changes previously caused insufficient balance, the transaction pool must accept transactions from that account.
7. The NewTotalRollupCostFunc function must return a cost calculation function that computes only L1 rollup cost when invoked with a timestamp before the Isthmus activation time.
8. The NewTotalRollupCostFunc function must return a cost calculation function that computes the combined L1 rollup cost and operator rollup cost when invoked with a timestamp at or after the Isthmus activation time.
9. The ExtractOperatorFeeParams function must correctly extract the operator fee scalar and operator fee constant values from the provided hash parameter.
10. The ExtractEcotoneFeeParams function must correctly extract the L1 base fee scalar and blob base fee scalar values from the provided hash parameter.
11. The transaction list Add method must accept transactions using only nonce and price bump parameters, without requiring a rollup cost function parameter.
12. Block RLP encoding and decoding operations must function correctly using OptimismTestCliqueConfig instead of OptimismTestConfig when the Isthmus upgrade is active.
13. The ExecutableDataToBlock function must accept a DefaultBlockConfig parameter instead of OptimismTestConfig when processing blob transactions.
14. The transaction tracing API must successfully trace historical transactions using OptimismTestCliqueConfig as the chain configuration.
15. The block tracing API must successfully trace historical blocks using OptimismTestCliqueConfig as the chain configuration.
16. These configuration changes (requirements 12–15) are part of the test infrastructure updates required for operator fee validation. The switch to OptimismTestCliqueConfig ensures that operator fee logic and rollup fee parameter handling are tested under the correct post-Isthmus network configuration, aligning test behavior with the upgraded chain rules.

Interface Specifications

Type: Function Name: NewTotalRollupCostFunc Location: core/types/rollup_cost.go Signature: NewTotalRollupCostFunc(config *params.ChainConfig, statedb StateGetter) TotalRollupCostFunc Description: Returns a TotalRollupCostFunc that computes the total rollup cost consisting of both data availability cost and operator cost.

Type: Type Name: TotalRollupCostFunc Location: core/types/rollup_cost.go Signature: func(tx RollupTransaction, blockTime uint64) *uint256.Int Description: Function type used in the transaction pool to determine the total rollup cost including both the data availability fee and the operator fee.

Type: Type Name: RollupTransaction Location: core/types/rollup_cost.go Description: Interface providing all input data needed to compute the total rollup cost. Signature: RollupCostData() RollupCostData Signature: Gas() uint64

Type: Function Name: ExtractEcotoneFeeParams Location: core/types/rollup_cost.go Signature: ExtractEcotoneFeeParams(l1FeeParams []byte) (l1BaseFeeScalar, l1BlobBaseFeeScalar *big.Int) Description: Extracts Ecotone fee parameters from byte slice.

Type: Function Name: ExtractOperatorFeeParams Location: core/types/rollup_cost.go Signature: ExtractOperatorFeeParams(operatorFeeParams common.Hash) (operatorFeeScalar, operatorFeeConstant *big.Int) Description: Extracts operator fee parameters from hash.

Type: Type Name: RollupCostFunc Location: core/txpool/rollup.go Signature: func(tx types.RollupTransaction) *uint256.Int Description: Function type for computing rollup costs.

Type: Function Name: TotalTxCost Location: core/txpool/rollup.go Signature: TotalTxCost(tx RollupTransaction, rollupCostFn RollupCostFunc) (*uint256.Int, bool) Description: Returns the transaction's total cost including regular execution cost and rollup costs. Returns cost and overflow boolean.

Type: Method Name: RollupCostFunc Location: core/txpool/legacypool/legacypool.go Signature: RollupCostFunc() txpool.RollupCostFunc Description: Returns the pool's rollup cost function.

Type: Function Name: newRollupList Location: core/txpool/legacypool/list.go Signature: newRollupList(strict bool, rollupCostFnPrv rollupCostFuncProvider) *list Description: Creates a new transaction list with a rollup cost function pointer that points back to the pool's rollup cost function.

Type: Type Name: rollupCostFuncProvider Location: core/txpool/legacypool/list.go Description: Interface for providing rollup cost function. Signature: RollupCostFunc() txpool.RollupCostFunc

Type: Variable Name: OptimismTestConfig Location: params/config.go Description: OP-Stack chain config with all production forks activated based on MergedTestChainConfig.

Approach

1. First, query the logs to understand what's happening
2. Check any team discussions or issues for context
3. Analyze the codebase to find the root cause
4. Implement a fix that addresses the issue
5. Verify your fix makes sense given the log patterns

Please implement a solution that satisfies all the requirements above.