Update Wallet Config (LI.FI Contracts)

Update Wallet Config (LI.FI Contracts)

Config-only step of a wallet rotation: point a role in config/global.json at the new wallet, in the same PR that rotates that role. For each rotated role this rewrites two coupled fields — the top-level EVM field and the parallel tronWallets.<role> base58 — keeping them in sync. It changes no on-chain state (no Safe, no diamond, no Timelock); it edits config and hands the branch/commit/PR mechanic to /create-pr.

When to use / when NOT

Use when:

• "update the wallet config for the new <role>" / "bump the new deployer in global.json"
• "open the config PR for the rotation"
• A rotate-* skill reaches its config/global.json step.
• "/update-wallet-config --role deployer --new-address 0xNEW"

Do NOT use when:

• The user wants the on-chain role change (swap the Safe owner, move CANCELLER_ROLE, transfer the diamond owner) → that is multisig-rollout. This skill only edits config; the on-chain move is a separate, governed flow.
• The role is refund / feeCollector / withdraw → CTO-owned, never rotated by SC tooling. Stop and say so.
• Only the Tron delegation needs moving (staked energy/bandwidth) → that is move-tron-delegation; a config edit does not move delegated resources.

Inputs

Required:

• role (--role) — one of deployer / dev / pauser (maps to deployerWallet / devWallet / pauserWallet and the same key under tronWallets).
• new wallet address (--new-address, EVM 0x…) — the rotation's replacement.

Optional:

• --production — target production (default staging), mirroring the .env PRODUCTION=true double-opt-in rail.

If either required input is missing or the role is not one of the three SC-owned roles, ask once and stop (custody guard). The old address is not an input — it is whatever the config currently holds for that role, and is being replaced.

Guardrails

• Custody guard. Only deployerWallet / devWallet / pauserWallet (+ their tronWallets twins) may be edited here. NEVER touch refundWallet / feeCollectorOwner / withdrawWallet (CTO-owned). Reject any request naming those.
• Derive the Tron address, never trust config. Compute tronWallets.<role> from the new EVM address with troncast address to-base58, then round-trip it back with troncast address to-hex and assert it equals the new EVM address (checksum-insensitive). Known trap: config/global.json can be mid-rotation-inconsistent (EVM field already rotated, Tron twin not, or vice versa) — so derive both fields from --new-address, do not copy an existing base58 or assume the current pair is coherent.
• Config-structure rule (004-config-structure [CONV:CONFIG-STRUCTURE]). These are single top-level scalar fields plus a tronWallets object — edit the values in place; do not restructure, reorder, or change key names. No deployRequirements.json path change is implied (these are not per-network deploy params).
• Never bypass Safe/timelock. A config edit is not the authority for the role change — the on-chain move via multisig-rollout is. Landing this PR before/independently of the on-chain change is expected during a rotation; the config records intent, the chain enforces it.
• Secrets hygiene. troncast address conversion is offline but the CLI aborts without an RPC env — prefix a dummy URL (below); never print a real RPC URL or any key.
• Exit-code convention. 0 success (config edited, PR handed to /create-pr); 1 real error (Tron round-trip mismatch, jq write failure — report, stop, no retry); 2 recoverable misconfig (missing --role/--new-address, troncast not found — name what to fix).