[amir-deris]

Bumps github.com/sei-protocol/sei-config from v0.0.28 to v0.0.29 in the root, sidecar and sidecarapi modules. Pins only; no source change. Part of PLT-1553.

What it unlocks

v0.0.29 carries sei-protocol/sei-config#54, which adds the 32 [evm] keys seid reads that the unified schema didn't model:

• 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 and tracing: max_filters, max_log_bytes, trace_allowed_tracers, trace_bake_* and others

Until the pin moves, the sidecar rejects these as unknown override key, and WriteConfigToDir drops them from app.toml. Managed nodes run on seid's compiled-in defaults with no way to tune them through spec.overrides. After this bump they can be set as evm.<seid key>, e.g. evm.ip_rate_limit_rps.

Effect on existing nodes

• Rendered files change, runtime doesn't. Rendered app.toml files now include all 32 keys, set to seid's defaults, so seid behaves exactly as before.
• Older files read safely. An app.toml rendered by v0.0.28 or earlier is missing these keys. On an incremental apply they read as defaults, not zeros, so the sidecar can't write back rate_limiting_enabled = false or max_filters = 0.
• Defaults are now pinned in the file. Because the keys are written explicitly, a future change to seid's own defaults for them won't reach controller-managed nodes until sei-config's defaults are updated to match.

[cursor]

PR Summary

Medium Risk
Changes how controller-managed app.toml is rendered and which EVM overrides are allowed, affecting RPC admission and rate-limit tuning on production nodes even though defaults aim to preserve current behavior.

Overview
Dependency-only change: pins github.com/sei-protocol/sei-config from v0.0.28 to v0.0.29 in the root module, sidecar, and sidecarapi (go.mod / go.sum only; no application code edits).

What the new pin enables: v0.0.29 models 32 [evm] settings that seid already reads (rate limits, request admission, filters/logs, trace/simulation knobs). On v0.0.28 the sidecar treated evm.* overrides for those keys as unknown and WriteConfigToDir omitted them from rendered app.toml, so managed nodes could not tune them via spec.overrides. After this bump, valid evm.<key> overrides are accepted and written through the existing ResolveIntent / config-apply path.

Operational note: the next full or incremental config apply will emit those keys in app.toml at sei-config’s pinned defaults, so on-disk config grows while runtime behavior should match today until operators override values. Older app.toml files missing the keys should still merge safely on incremental apply (per PR testing notes).

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

[seidroid]

Bumps sei-config from v0.0.28 to v0.0.29 in all three modules, which lets the 32 seid [evm] keys be set through spec.overrides; go.mod and go.sum change consistently and the module's own go.mod hash is unchanged, so no new transitive dependencies come in. Nothing blocks: the defaults in v0.0.29 match seid's DefaultConfig and pass the new Validate() checks (burst 200 ≥ batch limit 100), configValues drift is keyed on the spec hash rather than the library version so the bump rolls no nodes, and the tree was read at the PR merge ref. The codex reading found nothing, and that matches this review, so it adds no findings.

_{seidroid review · decision approve · session e3f0c5c9882f45bd9d0817c6e41ae04d · turn resp_claude_6aa3d2ddd112a180895842ec706e4c80 · item 4d97360f74615253904ff01188529e07}

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