Upgrade-path test planned; local dev chain judged not worth it for runs
Satsuma can upgrade a product it already runs: a vote on its chain points a proxy contract at a new implementation, so the product keeps its address and funds while its code changes. Claude, working in Claude Code, planned how that upgrade path gets tested: a live test in the next run, plus a hardhat test of the logic that picks which contract counts as the new implementation.
The proposed hardhat test would pull that selection, about 25 lines, out into a pure function and check it against a real proxy, the old implementation, a V2 and a plain contract. That covers the choice, but not the vote itself: "The vote's upgradeToAndCall on the real chain is the one step nothing but a run can test."
The same session looked at whether runs could use anvil, a local development chain, instead of a Satsuma node. The recommendation was that it is possible in principle but not worth it, because the cross-chain layer the runs depend on is real: ISMP pallets with on-chain GRANDPA light clients, and a relayer. The proposed test is waiting for the operator's go-ahead.
- How to test the upgrade path: a live test in the next run plus a hardhat test of how the new implementation is selected
- Whether runs could use an anvil/forge local chain instead of a Satsuma node, given cross-chain transactions
- Recommendation: replacing the Satsuma node with anvil is possible in principle but not worth it, because the cross-chain layer (ISMP pallets with on-chain GRANDPA light clients, relayer) is real
- Whether the operator wants the proposed hardhat test of the implementation-selection logic
- Whether the work is merged after the next run, or sooner if that run fails at the upgrade step
- Whether an earlier price-guard issue recurs in the next run and gets fixed through the upgrade path