[amir-deris]

Resolves PLT-1553.

Problem

sei-chain's [evm] section has 32 keys that SeiConfig doesn't model, including the new per-IP rate limiting. Because sei-k8s-controller renders node config through sei-config:

• ApplyOverrides rejects these keys as unknown override key, so the controller can't set them.
• WriteConfigToDir drops them from app.toml, so every managed node runs on seid's compiled-in defaults and the values can't be tuned.

Changes

• Fields: all 32 keys added to EVMConfig and legacyEVM, flat and with seid's exact key names (override key = evm.<seid key>), and mapped in toLegacyApp() / fromLegacy().
  • Rate limiting: rate_limiting_enabled, ip_rate_limit_rps, ip_rate_limit_burst, trusted_proxy_cidrs
  • Request admission: batch_request_limit, batch_response_max_size, max_request_body_bytes, max_concurrent_request_bytes, body_read_idle_timeout, ws_admission_timeout, max_open_connections, rpc_default_timeout, rpc_method_timeouts
  • Filters / logs / simulation: max_filters, max_block_filter_hashes, max_subscriptions_logs, max_log_bytes, enable_simulation, max_estimate_gas_calls, max_state_override_accounts, max_state_override_slots
  • Tracing: max_trace_struct_log_bytes, trace_allowed_tracers, trace_allow_js_tracers, enable_parallelized_block_trace, trace_bake_* (7 keys)
• Defaults: match seid's evmrpc/config.DefaultConfig, with no mode-specific overrides.
• Validation: validateEVM now rejects what seid refuses to start with:
  • max_filters / max_block_filter_hashes of 0
  • negative max_open_connections, body_read_idle_timeout, rpc_default_timeout
  • non-native tracer names
  • invalid trusted_proxy_cidrs
  • malformed rpc_method_timeouts
  • ip_rate_limit_burst < batch_request_limit when rate limiting is enabled
• Descriptions: enrichments added for all 32 keys.

Follow-up

• Release v0.0.29.
• Bump github.com/sei-protocol/sei-config in sei-k8s-controller.

[cursor]

PR Summary

Medium Risk
Changes how legacy app.toml is interpreted and what gets written on re-render; mis-seeding could alter production EVM RPC limits or rate limiting, though tests explicitly guard the migration path.

Overview
Adds 32 [evm] settings that seid already honors but sei-config did not—rate limiting, batch/body/connection admission, filter and log caps, simulation and state-override limits, trace allowlists and trace-bake options, and per-method RPC timeouts—so managed nodes can override and persist them in app.toml instead of silently dropping keys or rejecting ApplyOverrides.

Defaults match seid’s EVM RPC defaults; validateEVM now fails the same invalid combinations (zero filter limits, bad CIDRs/tracers/timeouts, burst below batch size when rate limiting is on). ReadConfigFromDir seeds only these new keys via newLegacyEVMForRead before decode so older app.toml files without them do not round-trip as zeros (which would disable rate limiting or block startup). evm_test.go covers round-trip, absent-key seeding, overrides, and validation.

^{Reviewed by Cursor Bugbot for commit 0a1a71c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[amir-deris]

@seidroid review

[seidroid]

Adds the 32 missing seid [evm] keys to EVMConfig and the legacy mapping, with seid's defaults, read-time seeding for older app.toml files, validation, and enrichments. I approve because the new validation matches seid's startup checks in evmrpc/config/config.go. One suggestion covers an edge case where the read-time seeding is stricter than seid. The codex reading (zero RPS should bypass the burst-vs-batch check) is dropped: seid applies the same check without exempting ip_rate_limit_rps = 0, so sei-config matches seid there. No Go toolchain was available, so the tests were not run.

Non-blocking

1 finding on the changed lines, as inline comments.

_{seidroid review · decision approve · session 98b271ef973a4fbf95c7ff16a2670b1a · turn resp_claude_b7435c9cd119174336b0e8069d7f34fc · item a27828c040d555f3bc3773e0314ea478}

Findings: 0 blocking | 1 non-blocking | 1 posted inline

[seidroid]

suggestion — When an app.toml has no rate_limiting_enabled key, this seeds it as true. seid treats an absent key more gently: it raises ip_rate_limit_burst to batch_request_limit and logs a warning instead of failing. seid versions between #3507 and #4403 wrote ip_rate_limit_burst without the switch, and one of those files with a burst below the batch limit now fails Validate() here. Re-rendering it also writes rate_limiting_enabled = true explicitly, which turns seid's warning into a startup failure. Consider applying the same burst raise when the switch was absent from the file, or recording that it was absent so the check can be skipped.

[amir-deris]

The difference is real, but its reach is much narrower than this suggests, so I'm leaving the code as is.

• The window is #3507 to #3779 (Jun 16 to Aug 5), not up to #4403. From #3779 on, seid's template writes rate_limiting_enabled explicitly (as false until #4403). With the switch off, the burst-vs-batch check doesn't run.
• Default values in that window pass. The template's default ip_rate_limit_burst was 400, and sei-config fills in batch_request_limit = 100. It only fails if an operator set the burst below 100 by hand.
• Controller-managed nodes don't have such files. Incremental apply reads app.toml files that sei-config itself wrote earlier. Those files have none of these keys, so the burst gets the default 200 as well. The case needs a file seid generated during that window, then hand-edited, then read by sei-config.
• It fails safely. Validate() errors and names ip_rate_limit_burst and batch_request_limit, the apply stops before writing anything, and a single override fixes it.

Matching seid's "raise the burst if the switch was missing" logic would mean tracking whether each key was present in the file. That isn't worth the complexity for a hand-edited file from a short window that has since closed.