feat(mcms): add transfer-to-timelock changeset [CLD-2762]#99
Conversation
Release impact (release-please)
PR title: Merging this PR as-is will contribute a minor bump to the next release-please release PR. Conventional commit → bump
Update the PR title before merge if you need a different bump (squash commit message = PR title). Preview is based on this PR title only. The release-please release PR may include other unreleased commits already on |
There was a problem hiding this comment.
Pull request overview
Adds a new ChangeSetV2 (“transfer-to-mcms”) that transfers ownership of ownable contracts to the MCMS timelock on EVM chains by (1) sending transferOwnership directly on-chain from the deployer and (2) batching acceptOwnership into an MCMS timelock proposal resolved from datastore refs.
Changes:
- Introduces a new transfer-to-MCMS changeset with a per-family registry and an
all/blank-import wire package. - Implements the EVM family sequence, datastore-backed validation, and generated “ownable” operations (owner/transferOwnership/acceptOwnership).
- Adds unit tests for validation/registry plus an E2E test proving ownership ends at the timelock after proposal execution.
Reviewed changes
Copilot reviewed 13 out of 14 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| mcms/evm/transfer-to-mcms/validate.go | EVM validation for MCMS refs, contract presence in datastore, and ownership preconditions. |
| mcms/evm/transfer-to-mcms/validate_test.go | Unit tests for MCMS ref resolution, datastore lookup, and ownership validation rules. |
| mcms/evm/transfer-to-mcms/v1_0_0/operations/burn_mint_erc677/burn_mint_erc677.go | Generated operations used as a generic “ownable” ABI surface. |
| mcms/evm/transfer-to-mcms/sequence.go | EVM sequence that performs transferOwnership and produces batched acceptOwnership txs for MCMS. |
| mcms/evm/transfer-to-mcms/register.go | Auto-registration of the EVM family implementation into the changeset registry. |
| mcms/evm/transfer-to-mcms/operations_gen_config.yaml | operations-gen config for ownable-like operations generation. |
| mcms/evm/transfer-to-mcms/generate.go | go:generate entrypoint to regenerate operations via operations-gen. |
| mcms/changesets/transfer-to-mcms/types.go | Changeset config/input/deps types and environment reconstruction helper. |
| mcms/changesets/transfer-to-mcms/registry.go | Family registry for per-chain-family transfer-to-MCMS sequences and verify hooks. |
| mcms/changesets/transfer-to-mcms/registry_test.go | Unit tests covering registration/lookup/verify behavior and error paths. |
| mcms/changesets/transfer-to-mcms/doc.go | Package docs and usage example for importing families/readers and running the changeset. |
| mcms/changesets/transfer-to-mcms/changeset.go | ChangeSetV2 implementation: precondition verification, per-chain dispatch, and output building with MCMS proposal. |
| mcms/changesets/transfer-to-mcms/changeset_evm_test.go | E2E test deploying LINK + MCMS, then transferring LINK ownership to the timelock via proposal. |
| mcms/changesets/transfer-to-mcms/all/wire.go | Convenience blank-import package for built-in families and required readers. |
Files not reviewed (1)
- mcms/evm/transfer-to-mcms/v1_0_0/operations/burn_mint_erc677/burn_mint_erc677.go: Generated file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ef5b835 to
9eb1ae1
Compare
9eb1ae1 to
18f655e
Compare
18f655e to
44c087b
Compare
| package transfertomcms_test | ||
|
|
There was a problem hiding this comment.
Can we rename to just changeset_test.go ? if there's some evm specific logic maybe we move it to the evm sequence tests instead?
There was a problem hiding this comment.
i been thinking of this, currently we have evm and solana test under mcms/changeset but this doesnt make sense as they are suppose to be chain agonistic, so i plan to move those chain specific test under evm and solana and the changeset will only have simple framework test. What do you think?
There was a problem hiding this comment.
Yeah that makes more sense, we can registered a moxk seqience here for tests
44c087b to
39a9b29
Compare
39a9b29 to
26f10e5
Compare
Introduce a ChangeSetV2 flow to transfer ownable contracts to the MCMS timelock, with per-family registry, EVM sequence, datastore validation, and an end-to-end test.
26f10e5 to
a9ec4cc
Compare
|
## Summary Adds a new `ChangeSetV2` transfer-to-timelock changeset ([CLD-2762](https://smartcontract-it.atlassian.net/browse/CLD-2762)) that moves ownable contract ownership to the MCMS timelock. The deployer sends `transferOwnership` on-chain; `acceptOwnership` is batched into an MCMS timelock proposal. - **`mcms/changesets/transfer-to-timelock/`** — family registry, changeset orchestration, `all` wire package, and E2E test - **`mcms/evm/transfer-to-timelock/`** — EVM sequence (operations-gen), validation (datastore contract lookup, ownership preconditions, `OnlyAcceptOwnership`), and unit tests MCMS timelock refs are resolved from the datastore via the MCMS reader registry, matching the pattern used by deploy and set-config.
To be merged after: #99 Implements the deploy custom topology changeset and sequences for EVM which allows users to deploy custom mcms / timelock structures without custom coding topologies. ## AI Summary This pull request refactors the EVM operations code in the MCMS legacy changesets by consolidating and updating imports to use a newer, centralized `evm/operations` package. The changes primarily involve replacing references to the old `oputil` and legacy operation types with the new `evmops` types and functions, improving maintainability and consistency across the codebase. No functional logic is altered; this is a structural cleanup. **Refactoring and Codebase Cleanup:** * Replaced all imports of `oputil` and legacy operation types in multiple files (such as `deploy_mcms_with_timelock.go`, `grant_timelock.go`, and various operation and sequence files) with the new `evmops` package from `mcms/evm/operations` for EVM operation utilities and types. [[1]](diffhunk://#diff-b2398611f89ecae075cf3fa2ebc54fffdb5be3053e22ec48a758b897a3fe4f2eL24-R26) [[2]](diffhunk://#diff-d65ee785393e80500d9a9e10b6be88af9066f272f273b3a495ca51eb62bcf1caL14-R16) [[3]](diffhunk://#diff-01347b473bc84fecfbfd6e74fc8d3ceab6f5f46df817b98912390a91abded6e9L23-R24) [[4]](diffhunk://#diff-d06b9c5105af450ff38a3d1088e63930739725c5d769c418e049501f2a9ee774L12-R25) [[5]](diffhunk://#diff-bbc03c83b6d0480e7d8522c83792e93540a723fd77538ee68aa6f4680b91d026L14-R14) [[6]](diffhunk://#diff-2ba3562716d4f675ca494b4cdd289784a1a11084bf6819b9fe02e3b129822741L12-R20) [[7]](diffhunk://#diff-6e44b5b90b68ec00183f14c09ca6f134d53654e8ee03c3cfe811033a07ccdf1dL12-R12) [[8]](diffhunk://#diff-f7f4b27536717322f79551fe53d332068a4a60df6ec498e5b17a504932fe953cL12-R25) [[9]](diffhunk://#diff-af27581a8ad86d0f1ecc0da7328dd4557658d19be900e98f4cd95b8588c6b3f2L17-R18) [[10]](diffhunk://#diff-1fd84ce86f315635e347f82581e4070196a811f934685fa1a908b24d67089ffeL17-R18) * Updated all usages of EVM operation constructors and types (e.g., `NewEVMDeployOperation`, `NewEVMCallOperation`, `EVMDeployInput`, `RetryDeploymentWithGasBoost`, `EVMCallOutput`, etc.) to use the new `evmops` equivalents, ensuring type compatibility and consistency. [[1]](diffhunk://#diff-b2398611f89ecae075cf3fa2ebc54fffdb5be3053e22ec48a758b897a3fe4f2eL259-R259) [[2]](diffhunk://#diff-b2398611f89ecae075cf3fa2ebc54fffdb5be3053e22ec48a758b897a3fe4f2eL271-R271) [[3]](diffhunk://#diff-d65ee785393e80500d9a9e10b6be88af9066f272f273b3a495ca51eb62bcf1caL204-R208) [[4]](diffhunk://#diff-d65ee785393e80500d9a9e10b6be88af9066f272f273b3a495ca51eb62bcf1caL245-R249) [[5]](diffhunk://#diff-01347b473bc84fecfbfd6e74fc8d3ceab6f5f46df817b98912390a91abded6e9L41-R47) [[6]](diffhunk://#diff-01347b473bc84fecfbfd6e74fc8d3ceab6f5f46df817b98912390a91abded6e9L59-R68) [[7]](diffhunk://#diff-01347b473bc84fecfbfd6e74fc8d3ceab6f5f46df817b98912390a91abded6e9L122-R122) [[8]](diffhunk://#diff-d06b9c5105af450ff38a3d1088e63930739725c5d769c418e049501f2a9ee774L12-R25) [[9]](diffhunk://#diff-bbc03c83b6d0480e7d8522c83792e93540a723fd77538ee68aa6f4680b91d026L26-R32) [[10]](diffhunk://#diff-2ba3562716d4f675ca494b4cdd289784a1a11084bf6819b9fe02e3b129822741L12-R20) [[11]](diffhunk://#diff-6e44b5b90b68ec00183f14c09ca6f134d53654e8ee03c3cfe811033a07ccdf1dL22-R22) [[12]](diffhunk://#diff-f7f4b27536717322f79551fe53d332068a4a60df6ec498e5b17a504932fe953cL35-R41) [[13]](diffhunk://#diff-f7f4b27536717322f79551fe53d332068a4a60df6ec498e5b17a504932fe953cL51-R57) [[14]](diffhunk://#diff-af27581a8ad86d0f1ecc0da7328dd4557658d19be900e98f4cd95b8588c6b3f2L48-R53) [[15]](diffhunk://#diff-af27581a8ad86d0f1ecc0da7328dd4557658d19be900e98f4cd95b8588c6b3f2L83-R94) [[16]](diffhunk://#diff-af27581a8ad86d0f1ecc0da7328dd4557658d19be900e98f4cd95b8588c6b3f2L122-R122) * Adjusted function signatures and return types throughout the EVM operation and sequence logic to use the new types from `evmops`, removing all direct dependencies on the deprecated `oputil` package. [[1]](diffhunk://#diff-01347b473bc84fecfbfd6e74fc8d3ceab6f5f46df817b98912390a91abded6e9L41-R47) [[2]](diffhunk://#diff-01347b473bc84fecfbfd6e74fc8d3ceab6f5f46df817b98912390a91abded6e9L59-R68) [[3]](diffhunk://#diff-01347b473bc84fecfbfd6e74fc8d3ceab6f5f46df817b98912390a91abded6e9L122-R122) [[4]](diffhunk://#diff-af27581a8ad86d0f1ecc0da7328dd4557658d19be900e98f4cd95b8588c6b3f2L48-R53) [[5]](diffhunk://#diff-af27581a8ad86d0f1ecc0da7328dd4557658d19be900e98f4cd95b8588c6b3f2L83-R94) [[6]](diffhunk://#diff-af27581a8ad86d0f1ecc0da7328dd4557658d19be900e98f4cd95b8588c6b3f2L122-R122) This update is a non-functional, structural refactor that will make future maintenance and enhancements easier by consolidating EVM operation logic in a single, modern package. --------- Signed-off-by: Pablo Estrada <139084212+ecPablo@users.noreply.github.com> Co-authored-by: Graham Goh <graham.goh@smartcontract.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>


Summary
Adds a new
ChangeSetV2transfer-to-timelock changeset (CLD-2762) that moves ownable contract ownership to the MCMS timelock. The deployer sendstransferOwnershipon-chain;acceptOwnershipis batched into an MCMS timelock proposal.mcms/changesets/transfer-to-timelock/— family registry, changeset orchestration,allwire package, and E2E testmcms/evm/transfer-to-timelock/— EVM sequence (operations-gen), validation (datastore contract lookup, ownership preconditions,OnlyAcceptOwnership), and unit testsMCMS timelock refs are resolved from the datastore via the MCMS reader registry, matching the pattern used by deploy and set-config.