Offboard SC Dev (LI.FI Contracts)

Offboard SC Dev (LI.FI Contracts)

Drives the smart-contract half of offboarding a departing SC team member: remove them as a Safe multisig signer, add their replacement, and rotate every shared wallet they had custody of to a freshly generated one. This is the orchestrator — it calls the per-role rotate-* skills and multisig-rollout; it does not reimplement any rotation.

v1 scope — EXECUTE-ONLY. This skill assumes the offboarding Linear ticket tree already exists (created by hand, modeled on EXSC-558) and its job is to execute that plan. It does not generate the ticket tree. Auto-creating the tickets is a deliberate fast-follow — call it out at the start so the user knows to have the tree ready, and don't silently skip a step because a ticket is missing.

Why an orchestrator and not one big script: each role has a different rotation mechanism (Safe owner swap, staging owner transfer, immutable-facet redeploy), and each is independently useful and independently tested. This skill sequences them by dependency and holds the custody guard across all of them.

When to use / when NOT

NOT for non-SC offboarding (HR/IT deprovisioning is out of scope) and NOT for rotating a CTO-owned wallet (refund / feeCollector / withdraw — see custody guard).

Inputs

• --person <name> — the departing SC dev, resolved from the offboarding Linear tree (EXSC-558-style).
• --removed-signer 0x — the departing person's personal multisig signer seat to remove (human-supplied / ticket-sourced).
• --new-signer 0x — the replacement personal multisig signer to add (human-supplied / ticket-sourced).
• --linear EXSC-XXX — the parent offboarding ticket (the pre-existing tree this run executes). If absent, ask for it — do not invent a tree.
• New wallet addresses for deployer, dev, pauser — securely generated by a human (the blocking first step, below). Old addresses are derived from keys / on-chain state, never from config/global.json (it can be mid-rotation-inconsistent).

Guardrails

• Custody guard. Rotate only the SC-owned shared wallets (deployer, dev, pauser) plus swap the departing person's personal multisig signer seat. NEVER rotate the CTO-owned refund / feeCollector / withdraw — if the ticket tree implies touching one, stop and escalate.
• Never self-sign. New-key generation is a human step. Every Safe proposal (signer swap, deployer's Safe-owner / CANCELLER moves, pauser diamond cuts) is human Ledger-signed via multisig-rollout → script/deploy/safe/confirm-safe-tx.ts; this skill and the ones it calls hand off and WAIT — none run the signer.
• Never bypass Safe/timelock (rule 002-architecture). All owner/role/pauser on-chain changes go through multisig-rollout — no direct cuts, no SEND_PROPOSALS_DIRECTLY_TO_DIAMOND=true.
• Secrets hygiene. Never print a private key or full RPC URL. Derive every old address from its key or on-chain state, never from config/global.json.
• Exit-code convention for sub-skills / scripts: 0 success; 1 real error (report, stop, no retry); 2 recoverable misconfig (name the missing env/credential). A failing network in one rotation must not silently abort the others — surface it and let the operator decide.
• Scripting is TypeScript (bunx tsx) or Bash only, never Python. Foundry/bun may need export PATH="$HOME/.foundry/bin:$HOME/.bun/bin:$PATH".

Workflow

Ordered by dependency. The new keys must exist and be funded before anything on-chain can move, so key generation is the blocking first human step; the signer swap and deployer rotation come next because they change who can sign; dev and pauser follow; secret rotation and the completeness gate close it out.