[aregng]

Summary

MultiSignatureWallet is no longer an automation task owner. Tasks the foundation wants registered are owned by a separate task owner contract that the wallet administers.

• MultiSignatureWallet no longer declares IAutomationTaskOwner and has no supportsInterface. The registry refuses it as the owner of a user task and of a system task with UnsupportedTaskOwner.
• New src/libraries/LibTaskOwner.sol holds the registry's task owner rule (#4469): an account without code, an EIP-7702 delegated account, or a contract that declares IAutomationTaskOwner through ERC-165. LibRegistry.registerTask and ConfigFacet.grantAuthorization both apply it, so grantAuthorization now refuses an account the registry would refuse as a task owner, the wallet included; IConfigFacet declares the error (UnsupportedTaskOwner, the registry's selector) so the ConfigFacet ABI decodes it. The AuthorizeAccount governance action checks the same library before submitting, instead of keeping its own copy.
• IAutomationTaskOwner is unchanged from the base branch. The rules for the foundation's own task owner contract are a governance rule, stated in the README and the grantAuthorization NatSpec: governance may authorize any account the registry accepts, never one that holds authority over other contracts, and the foundation's own system tasks go through a contract the wallet administers and uses for nothing else.
• New src/SystemTaskOwner.sol, a reference task owner for system tasks on AutomationTaskOwnerBase: Ownable2Step ownership that cannot be renounced; owner-only registerSystemTask (all of the registry's parameters), cancelSystemTasks, stopSystemTasks and withdrawFunds; native SUPRA refused, since system tasks are charged no fees. It is not deployed at genesis.
• solidity/supra_contracts/README.md, "Automation tasks of the foundation": the procedure (write the contract, with SystemTaskOwner as the reference; deploy it through the wallet's deployContract so that the wallet is its owner; authorize it with AuthorizeAccount; register, cancel and stop through wallet transactions to it) and the rules for that contract and its tasks.
• Pinned genesis bytecode hashes in crates/supra-extension/src/contracts/generator.rs regenerated from a release build of the tree merged with feature/evm_automation ([#4921] Price EVM user tasks on task occupancy as well as gas occupancy #85, [#4936] Keep BlockMeta ownership recoverable: two-step transfer, no renunciation #87): MultiSignatureWallet, ConfigFacet, RegistryFacet.

Motivation

The foundation wallet's authority stays inside its submit, confirm and execute flow; automation tasks are owned by a dedicated contract the wallet administers. The analysis is in the tracking issue: Entropy-Foundation/smr-moonshot#4922.

Notes for reviewers

• No governance actions deploy or drive SystemTaskOwner yet. They are written once the foundation has a concrete system task, against that task's requirements; until then the contract is reviewed reference code with tests, and test/ContractOwnedTasks.t.sol runs the whole procedure through wallet transactions.
• That the task owner contract holds no other authority is a documented governance rule; the contracts do not check it.
• The wallet's ABI loses supportsInterface, and the genesis bytecode of the wallet, ConfigFacet and RegistryFacet changes. The node-side follow-up (new revm rc pin, the e2e test that registers a system task from the wallet, the Integration book pages) is tracked in Entropy-Foundation/smr-moonshot#4996.

Test plan

• forge test in solidity/supra_contracts, default and production profiles: 661 passed, 0 failed (on the merged tree).
  • test/ContractOwnedTasks.t.sol:
    • the wallet declares neither IERC165 nor IAutomationTaskOwner;
    • grantAuthorization refuses the wallet and a contract that does not declare IAutomationTaskOwner, with the error IConfigFacet declares;
    • an authorized account whose code no longer declares the interface cannot register a system task;
    • the wallet is refused when registering a user task;
    • a system task registered through a wallet-deployed SystemTaskOwner is owned by that contract, and the wallet cancels it through it;
    • neither a single wallet owner nor the wallet directly on the registry can stop it.
  • test/SystemTaskOwner.t.sol: ownership and registry binding, the declared interfaces, register and stop by the owner, every acting function owner-only (including a call from the contract itself), two-step ownership, renunciation disabled, native SUPRA refused, WSUPRA withdrawn by the owner.
  • test/GovActions.t.sol: AuthorizeAccount refuses the foundation wallet and authorizes a contract that declares IAutomationTaskOwner.
• script/check_facet_selectors.sh
• cargo build --release --workspace
• cargo clippy --release --workspace --all-targets --all-features
• cargo nextest run --release --workspace: 556 passed, 1 skipped (includes genesis_contract_bytecode_matches_expected_hashes)

🤖 Generated with Claude Code

[isaacdoidge]

Reviewed at 987ec6c.

1. The smr-moonshot e2e suite and Integration book still treat the wallet as a task owner.

• remote_env/integration_suite/evm_automation_tests/__main__.py register_system_task_through_foundation_wallet authorizes the wallet, registers a system task from it and asserts the wallet owns it. With this change the registration reverts with UnsupportedTaskOwner(wallet). The test runs in every e2e run (e2e_suite/__main__.py:151).
• docs/guide/books/integration/src/network/evm/automation/how-automation-works.md:438,447,461 and docs/guide/books/integration/src/network/evm/system-contracts/automation-registry.md:358 state that the wallet declares IAutomationTaskOwner and owns system tasks.

The smr PR that bumps the revm pin needs to move the e2e test to a wallet-deployed task owner contract and update those pages. "Notes for reviewers" names only the pin bump.

2. The new obligation in IAutomationTaskOwner (src/interfaces/IAutomationTaskOwner.sol:33-36) applies to every contract task owner, not only the foundation's.
IAutomationTaskOwner is the interface third-party contracts declare to own user tasks; the Integration book's getting-started page tells integrators to declare it. "It is used for nothing except its tasks: it is not the owner, admin or role holder of another contract, and holds no funds or allowances beyond those its tasks need" excludes, for example, a contract that holds user funds and registers its own upkeep task, which the registry accepts. The rule is a governance rule for the task owner the foundation wallet administers. Suggest stating it in the README section and the grantAuthorization NatSpec, and leaving the interface's obligations as they were.

3. Steps 1, 2 and 4 of "Automation tasks of the foundation" have no governance action.
submit_governance_action.sh runs the actions in script/GovActions.s.sol (InitializeCycleMonitoring, AuthorizeAccount, EnableDisableAutomation), which cover step 3 only. Writing the contract, deploying it through deployContract, and registering, cancelling and stopping its tasks each require the owners to write Solidity and encode wallet transactions by hand. The example the README names, AdminAutomationTaskOwner, is a test fixture (test/AutomationTaskOwnerBase.t.sol:15-69) with a fixed 100,000 gas, priority 2, a 4 gwei gas price cap and a 60.1 ether fee cap. Suggest a parameterised task owner contract in src/ and governance actions that deploy it and register, cancel and stop through it, so that the procedure runs reviewed code.

4. AuthorizeAccount.canOwnTasks (script/GovActions.s.sol:189-198) is a second copy of LibRegistry.validateTaskOwner (src/libraries/LibRegistry.sol:76-88).
The two match today, and the comment says they must be kept in step. The check also runs only in the script: ConfigFacet.grantAuthorization (src/facets/ConfigFacet.sol:26-32) still accepts the wallet when called directly. An alternative is to enforce the rule in grantAuthorization through a library function both sites share, and drop the script's copy.

[aregng]

Thanks for the review. Addressed in 49da227:

1. smr e2e suite and Integration book. Tracked in Entropy-Foundation/smr-moonshot#4996, the follow-up that moves the node to the next revm rc. It lists register_system_task_through_foundation_wallet (to move to a wallet-deployed task owner, keeping an assertion that authorizing the wallet is refused) and the how-automation-works.md and automation-registry.md pages, together with the other fork changes since rc25.

2. IAutomationTaskOwner obligation. Reverted: the interface is as on feature/evm_automation. The rule is now stated where it belongs, as a governance rule for the foundation's task owner, in the README section and the grantAuthorization NatSpec.

3. Steps without a governance action. Partly taken. src/SystemTaskOwner.sol is added as a reviewed, parameterised reference: registerSystemTask takes all of the registry's parameters, ownership is two-step and cannot be renounced, and it refuses native SUPRA. The README's step 1 points to it instead of the test fixture, and test/SystemTaskOwner.t.sol and test/ContractOwnedTasks.t.sol cover it and the procedure through wallet transactions.
We decided not to add governance actions that deploy and drive it in this PR: they are written once the foundation has a concrete system task, against that task's requirements. The README says so.

4. Duplicate task owner rule. Done as suggested: src/libraries/LibTaskOwner.sol holds the rule, LibRegistry.registerTask and ConfigFacet.grantAuthorization both apply it, and AuthorizeAccount calls the same library; the script's copy is gone. grantAuthorization now refuses the wallet when called directly. test/ContractOwnedTasks.t.sol also checks that registration still applies the rule to an already authorized account.

[isaacdoidge]

Reviewed at 49da227. The four points from the previous review are addressed; the governance actions for SystemTaskOwner are deferred as the README and the PR description state.

Merge conflict. The branch conflicts with feature/evm_automation after #85 and #87 merged. git merge-tree reports one conflicting file, crates/supra-extension/src/contracts/generator.rs, in the pinned genesis bytecode hashes. ConfigFacet.sol, RegistryFacet.sol and LibRegistry.sol merge textually, but #85 also changed those contracts, so the merged hashes are neither side's: regenerate ConfigFacet, RegistryFacet and MultiSignatureWallet from a release build of the merged tree, and rerun forge test and genesis_contract_bytecode_matches_expected_hashes there.

UnsupportedTaskOwner from ConfigFacet. grantAuthorization now reverts with IRegistryFacet.UnsupportedTaskOwner, which IConfigFacet does not declare (IRegistryFacet.sol:102). A client decoding with the IConfigFacet ABI does not recognise the error. Declaring it in IConfigFacet as well, or listing it under grantAuthorization in the Integration book's error table (smr-moonshot#4996), would cover it.

[aregng]

Thanks. Both addressed:

Merge conflict. 64c062de merges feature/evm_automation (#85, #87). The pinned hashes are regenerated from a release build of the merged tree: ConfigFacet and RegistryFacet take new values, MultiSignatureWallet keeps this branch's. On the merged tree, genesis_contract_bytecode_matches_expected_hashes passes and forge test passes 661/661 in the default and production profiles.

UnsupportedTaskOwner from ConfigFacet. 462ccdc8 declares it in IConfigFacet too, with the same selector. testGrantAuthorizationRefusalIsDeclaredByIConfigFacet pins the two selectors together and checks that grantAuthorization reverts with the IConfigFacet declaration. The compiled ConfigFacet ABI already listed the error, since solc includes errors raised through the libraries a contract uses; the IConfigFacet interface ABI was the one missing it. The contract ABI now lists it twice, as it already does TransferFailed().