Compound: research & derisk crosschain call surface

[wildmolasses]

Compound sets market params crosschain. we want to make sure that our veto governor's timelock can adequately manage the crosschain calls for some specific subset of markets. let's make sure we understand how market params are set, so that we can propose a workable permission setup for managing these markets via council governance.

[thelostone-mc]

@wildmolasses Wrote up a script to query compounds proposals to filter out cross-chain proposals

Code: https://github.com/withtally/optimistic-governance/tree/cross-chain/research
Fetched all proposals from tally for compound

• For each proposal, filtered out proposals where executeableCall[i].chain != mainnet (this yielded 0 results) OUTPUT HERE
• Then for each proposals, i got the unique target INPUT and ran a script to see if [any of them are not EOA](https://github.com/withtally/optimistic-governance/blob/cross-chain/research/filter-contract-targets.mjs#L70-L72)
  That yielded 0 as well which means all executes call targets were EOA and not contracts
  Would love for you to gut check this assumption but i don't think there are any proposals from compound which use cross-chain bridges.

[thelostone-mc]

Overview

On the destination chain. Compound deploys

• Timelock which has a by compound has a Bridge Receiver
• The Bridge Receiver has govTimelock which is set to the etherum mainnet timelock address
• And it processes proposals only if the sender == govTimelock

Summary

• Once we deploy the council governance
• On the destination chain, we need to update the BaseReceiver.sol govTimelock to the respective council's veto timelock

What does this mean ?

• Looking at BaseReceiver.sol it doesn't look like govTimelock can be updated. This likely means we have to deploy a new BaseReceiver for each destination chain
• For every council wanting to maintain ownership of executing cross-chain
  • Deploy a new BaseReceiver on the destination chain
  • Set BaseReceiver.govTimelock to the councli veto timelock
  • Update the Compound Timelock on the destination chain admin to the new BaseReceiver

What does this mean

• Only 1 BaseReceiver can be admin of compound timelock on destination chain
• Currently BaseReceiver has only 1 govTimelock which cannot be updated
• Whoever is BaseReceiver.govTimelock has complete control on what proposal gets executed (which makes sense)

Contracts

• Mainnet
  • Timelock: 0x6d903f6003cca6255D85CcA4D3B5E5146dC33925
• Base
  • Timelock: 0xCC3E7c85Bb0EE4f09380e041fee95a0caeDD4a02
  • Bridge Receiver : 0x18281dfC4d00905DA1aaA6731414EABa843c468A
  • BridgeReceiver.sol : Only Mainnet Timelock 0x6d...3925 can process
• Optimism:
  • Timelock: 0xd98be00b5d27fc98112bde293e487f8d4ca57d07
  • Bridge Receiver: 0xC3a73A70d1577CD5B02da0bA91C0Afc8fA434DAF
  • BridgeReceiver.sol : Only Mainnet Timelock 0x6d...3925 can process
• Arbitrum
  • Timelock: 0x3fB4d38ea7EC20D91917c09591490Eeda38Cf88A
  • Bridge Receiver: 0x42480C37B249e33aABaf4c22B20235656bd38068
  • BridgeReceiver.sol : Only Mainnet Timelock 0x6d...3925 can process
• Polygon
  • Timelock: 0xCC3E7c85Bb0EE4f09380e041fee95a0caeDD4a02
  • Bridge Receiver: 0x18281dfC4d00905DA1aaA6731414EABa843c468A
  • BridgeReceiver.sol : Only Mainnet Timelock 0x6d...3925 can process
• Scroll
  • Timelock: 0xF6013e80E9e6AC211Cc031ad1CE98B3Aa20b73E4
  • Bridge Receiver: 0xC6bf5A64896D679Cf89843DbeC6c0f5d3C9b610D
  • BridgeReceiver.sol : Only Mainnet Timelock 0x6d...3925 can process
• Mantle
  • Timelock: 0x16C7B5C1b10489F4B111af11de2Bd607c9728107
  • Bridge Receiver: 0xc91EcA15747E73d6dd7f616C49dAFF37b9F1B604
  • BridgeReceiver.sol : Only Mainnet Timelock 0x6d...3925 can process

[thelostone-mc]

Possible Implementation

Option A (no code changes)

• Flow
  • For every council wanting to maintain ownership of executing cross-chain
  • Deploy a new BaseReceiver on the destination chain
  • Set BaseReceiver.govTimelock to the councli veto timelock
  • Update the Compound Timelock on the destination chain admin to the new BaseReceiver
• Downside
  • Original mainnet timelock can no longer execute proposals via Bridge Receiver

Option B (modify BaseReceiver)

• Flow
  • Modify BaseReceiver to either
    • Flavour A: haveupdateGovTimelock which let's us update the govTimelock (avoids deploying a new BaseReceiver each time )
      • Downside : Only 1 timelock will be able to send proposals to BaseReceiver
    • Flavour B: be able to handle multiple govTimelocks (which means mainnet timelock and multiple council veto timelock can send proposals to BaseReceiver on the destination chain )
      • Downside : No restrictions for any of the govTimelocks have same permissions on the BaseReceiver
    • Flavour C: same as option B but we implement AccessManager and take advantage of setTargetFunctionRole to ensure which call functions can be called by a given council vet timelock
      • Downside : Feels like we are over-engineering

Option C (enable multiple executors on the compound governor timelock via a shim)

• Flow
  • We'd implemented a TimelockMultiAdminShim as a part of governance rollback. This contract would have to be modified to use AccessManager
  • then every council veto governor would be added as an executor
  • the setTargetFunctionRole would be used to restrict what functions it can call
  • Downside
    • We are touching the main compound governor timelock which might have unwanted side-effects
    • management overhead of which council can do what

[thelostone-mc]

My suggestion

• If the requirement states that only 1 council governor should be the admin for cross-chain interaction and the main compound governor timelock will not execute cross-chain proposals , we should implement Option A
• If the requirement states that only multiple council governors and/or compound governor timelocks should be able to execute cross-chain proposals , we should implement Option B.Flavour B

---

I do feel that target gating for council veto governor is an overkill as

• council members are trusted actors
• even if a bad proposal is proposed, it can still be vetoed by the token holders (so it is impossible for a bad proposal to skip the veto step )

[funkyenough]

Maybe we can set the veto governor timelock to the mainnet compound governor timelock?

Compound multichain architecture assumes a single governor timelock on mainnet, and if we use any other timelock for the optimistic governance system, we will need to alter the contracts.

If we can grant veto governors the PROPOSER_ROLE and EXECUTOR_ROLE, we can queue all proposals from both compound governor and veto governors to a single timelock. That way we don't need to change any contracts.

[thelostone-mc]

@funkyenough yup the only issue that compound time lock doesn't use roles and instead allows allows proposals from 1 admin ( aka the governor )

This means we'd have to implement a shim ( checkout option C ) which allows multiple executors ( governors in our case ) to use the same timelock

[funkyenough]

Understood. Thanks for the clarification!

[thelostone-mc]

As per internal discussion, we'll be proceeding with option B flavor C

[thelostone-mc]

• AccessManager validates msg.sender (AccessManaged.sol:56)
• We need to validate rootMessageSender
• Execution order issue:
  • When bridge calls processMessage()
  • msg.sender = bridge contract,
  • but _rootMessageSender = actual governor/council governor.

Modifiers execute before function body, so parameters aren't available when _msgSender() is called :/
This means we'll have to implement the solution ourselves (not complicated though)

@funkyenough @wildmolasses