Guidance for AI coding agents (and humans) working in this repository. It explains what this repo does, the non-negotiable safety constraints for governance operations, and where the canonical workflow docs live.
This repo secures real value across the Superchain. Every task here ultimately becomes a multisig transaction that changes protocol parameters, upgrades contracts, or moves ownership. A mistake can be irreversible. Treat every change as high-risk and verify at every level.
superchain-ops contains governance operations for the Superchain: multisig transaction tasks, upgrade procedures, and configuration changes. Each governance action is a discrete, reviewable task with its own configuration and an explicit validation file that signers use to confirm what they are signing.
- Safe multisig — multi-signature wallets control protocol parameters. Most operations require N-of-M signers, and many are nested (a Safe whose owners are themselves Safes).
- Task — a self-contained directory describing one governance action. Tasks are reusable instances built on top of templates.
- Template — reusable Solidity code that standardizes how a class of tasks is
built and executed (for example
L2TaskBase,SimpleTaskBase,OPCMTaskBase). - Validation file — every task ships a
VALIDATION.mdso signers can independently verify they are approving the intended operation. When signing with a hardware wallet, signers see only cryptographic hashes, not human-readable details; the validation file bridges that gap with the expected domain/message hashes, a breakdown of the calls, and the expected state changes. - Simulation — operations are simulated against forked mainnet/testnet state (via Tenderly) before they are signed, so every state diff can be reviewed in advance.
src/tasks/eth/— Ethereum mainnet tasks.src/tasks/sep/— Sepolia testnet tasks.src/template/— reusable Solidity templates for tasks.src/script/— Foundry scripts and helpers.test/— Foundry tests, including the template regression suite.docs/— canonical human-facing workflow documentation (see below).runbooks/— operational runbooks.
Tasks are named in ascending lexicographical order using the format
[network]/[###]-[descriptive-name] (for example eth/001-first-task). Run
just task ls from src/ to see the current ordering for a network.
These apply to every governance task:
- Every task has a
config.toml, aREADME.md, and aVALIDATION.md. - Calldata must be independently verifiable — no opaque blobs. A reviewer must be able to reconstruct exactly what the transaction does.
- Simulations must pass against forked state before signing. Every state diff must be explainable; never sign or approve a task with an unexplained state change.
- Every address reference must be verified against the canonical Superchain Registry.
- Timelock periods must be documented and respected for upgrades.
VALIDATION.mdmust be complete with the correct domain and message hashes and all expected state changes documented.
-
Scaffold from an existing template:
cd src/ just new taskFollow the prompts to create a task directory with pre-populated
README.mdandconfig.toml. -
Fill in the task configuration and write a complete
VALIDATION.md. -
Run a Tenderly simulation and review every state change before requesting review:
just --dotenv-path $(pwd)/.env simulateFor a task that depends on others, prefer the stacked simulation from
src/:just simulate-stack <network> <your-task-name>
-
Open the Tenderly link, verify every state diff against your
VALIDATION.md, and confirm there are no unexpected changes. As the author you are responsible for understanding the full impact; reviewers and signers rely on your analysis.
See docs/NEW_TASK_GUIDE.md for the full task
lifecycle and the pre-submission checklist.
Templates standardize and secure task execution. Scaffold one with:
cd src/
just new template <l2taskbase|simpletaskbase|opcmtaskbase>A new template must be exercised by the regression suite
(test/tasks/Regression.t.sol) with an accompanying example task, or CI
(template_regression_tests) will fail. See
docs/NEW_TEMPLATE_GUIDE.md.
Dependencies are managed with mise; see
CONTRIBUTING.md for setup. Then:
just install # build the repo (from the root)
cd src/ && just test # run before requesting review on any PRReviewers should reproduce the author's work independently rather than trusting the description:
- Verify every address against the Superchain Registry.
- Re-run the simulation and confirm each state diff matches
VALIDATION.md. - Independently verify the calldata — at least one reviewer must reconstruct it from first principles.
- Confirm
VALIDATION.mdis complete and the task status is set appropriately.
Several of the steps above are automated by skills from the op-eng-skills
plugin — prefer them over doing the work by hand:
superchain-ops-task-review— review a task PR with Security-team rigor: verifies inputs against authoritative sources, runs simulations, and drafts review comments. Run it from within this repository.superchain-ops-template-review— the equivalent review for new or changed templates.safe-tx-verify— verify a Safe multisig transaction before signing: parses the Safe{Wallet} URL, decodes the calldata, computes the EIP-712 hashes, and returns a Go/No-Go decision.superchain-config— query Superchain chain configurations and contract addresses from the canonical Superchain Registry (use it for the address-verification step).
The docs/ directory is the source of truth for detailed workflows:
| Document | Description |
|---|---|
docs/NEW_TASK_GUIDE.md |
Creating a new task from an existing template |
docs/NEW_TEMPLATE_GUIDE.md |
Creating a new template |
docs/SINGLE.md |
Single-safe execution workflow |
docs/NESTED.md |
Nested-safe execution workflow |
docs/SINGLE-VALIDATION.md |
Validation patterns for single-safe operations |
docs/NESTED-VALIDATION.md |
Validation patterns for nested-safe operations |
For contribution setup and tooling, see CONTRIBUTING.md.