Three-step rollout recommended for 30 days of RPC history

A change to Satsuma's chain has been committed. It keeps 30 days of history behind the public eth RPC, the Ethereum-style connection point that apps and wallets use to read the chain, and fixes the 502 errors that batch requests were getting back.

Asked whether to deploy, Claude, working in Claude Code, recommended deploying now, in three steps and in this order: the batch fix in nginx, then archive mode for eth-rpc, the adapter that answers Ethereum JSON-RPC requests, then new pruning flags on one of the chain's validator nodes, in a watched window. Per the plan, production changes are run by the operator (the one person who runs the chain), not from an agent session.

The nginx change is one config line plus a reload, tested locally against the same failure seen in production. Archive mode restarts only eth-rpc: the public endpoint blips for a few seconds and finality is unaffected. Waiting for the validator's next planned restart was ruled out, because old block data is deleted at one block every 2 seconds and "The 30-day window only starts counting from the restart, so every day of delay is a day of history /eth will never have."

No deploy is recorded, and whether the operator runs the three steps is open. Restarting the validator briefly pauses finality, because all three validators are needed to finalize; the timing of that window is undecided.