1. All good:
   npx hardhat deploy --network loccal --clear --no-confirm

2. Prompts and it shouldnt
   npx hardhat deploy --network loccal --no-confirm

Multiple experiments were carried out to see if we can have modules interact with each other with a lower gas cost:

• https://github.com/Synthetixio/synthetix-v3-labs/tree/master/proxy-architecture-poc-5#communication-between-modules
• https://github.com/Synthetixio/synthetix-v3-labs/tree/master/intermodule-communication-poc1

The conclusion of these experiments was to try to not only generate the Solidity code of the router, but also generate a mixin that any module can inherit, exposing the addresses of all the modules via constants.

This poses many challenges:

1. The mixin needs to be generated before the modules are deployed, and since the module addresses are not known before they are deployed, it becomes a chicken vs egg problem. However, we can predict what module addresses will be, since they are deterministically calculated from the address of the deployer EOA (or contract?) and its nonce.

2. Since a project may target multiple networks/instances, it may have multiple routers such as RouterLocal.sol, RouterKovan.sol, etc. This duplication should also apply to this mixin. The duplication in the router code is ugly but tolerable, but the duplication in the mixin would be too weird. I.e.

contract AModule is RegistryMixinLocal { ... }
or
contract AModule is RegistryMixinKovan { ... }

A solution to this issue could be to have a single mixin:
contract AModule is RegistryMixin
and allow it to change depending on the last deployment. This means that this Solidity file will be constantly changing, depending on what the last targeted network was. Which is weird too, but tolerable.

In fact, if this works, the same principle could be applied to the router, effectively removing the need to keep multiple routers around in the codebase. Since the deployer always has all the necessary data to generate a new router, then why keep duplicates around, or even keep any around in the source code?

Generation process

Basic (excessive gas usage on deployment)

• Generate a fake AddressMixin with random addresses
• Compile all modules to find out the ones that changed due to explicit code change and by using the mixin
• Identify all contracts to deploy (and the order that will be used)
• Calculate and collect all modules new addresses
• Fill the missing modules addresses (the ones that weren’t re-deployed) using latest deployment info on the instance
• Generate a new AddressMixin with the right addresses
• Deploy all system (it will always deploy ALL MODULES that depends on AddressMixin)
• Validate that the AddressMixin has the right addresses

This process will always try to generate a new AddressMixin even if no modules were updated on the first time

Improved Process (only deploy when a module was updated)

• First identify if any module was updated
• If any module was updated, continue with the Basic process. If not, the current AddressMixin is still valid

it will deploy ALL MODULES that depends on AddressMixin when any module was updated

Improved Process 2 (tag Addressable modules)

This improvement also adds a tag to the modules that are addressable (the ones that are potentially usable from another module, and hence has the address exported in AddressMixin)
i.e. // address-mixin isAddressable

• Set a tag on the Modules source (this is done only once while coding and the tag can be added later if there's a need to use a module that wasn't set originally as addressable)
• Identify Modules that are addressable and check if any was updated
• If any addressable module was updated, continue with the Basic process. If not, the current AddressMixin is still valid

it will deploy ALL MODULES that depends on AddressMixin when any addressable module was updated

POC / docs here: https://github.com/Synthetixio/synthetix-v3-labs/tree/master/intermodule-communication-poc1

npx hardhat deploy --network local --clear --no-confirm
All good. Generates 2021-09-06-00.json.

npx hardhat deploy --network local --no-confirm
Does not generate a new file, which is good, since no changes means that a new deployment file didn't need to be generated.
However, it generates the router. This task could be skipped since there is no need to generate a router if no modules changed. So, no green output in the console. Perhaps even gray output specifying the no-op could help.
Similarly, it prints "Deployment marked as completed" in green. This is also a no-op.

The idea would be to only see colors when things happen during a deployment.

• Stop using hre.deployer.paths
• Do not use config in any tools - tools should only use primitives that are very intuitive
• Do not copy config.paths into config.deployer.paths
• Do not use config.deployer for anything dynamic, since this is supposed to be just config
• Forbid usage of .previousData in hre.deployer?
• Forbid usage of .file in hre.deployer?
• Is config.deployer.proxyName used?
• Document argument-types.js util
• Split out some functions in contracts util to core-js
• Move logger to core-js
• Move git and package to core-js
• Move prompter to core-js
• Move relative-path to core-js
• Move string to core-js
• Split deployer utils to internal/external utils: Internal are those that need the hre env, and external are the ones that dont - E.g. transactions.js

https://github.com/Synthetixio/synthetix-v3-labs/tree/master/proxy-architecture-poc-5

https://github.com/Synthetixio/synthetix-v3

https://docs.google.com/document/d/1eNwV5uTrIovy-f5CsmaHIA-EQExvdoCTK9Hao3uuqo8

https://github.com/Synthetixio/synthetix-v3/projects/1

Steps to reproduce:

• have a basic system working
• deploy it: npx hardhat deploy --network local --clear
• create a new module/contract with a function similar to other contract (same name and parameters)
• deploy it: npx hardhat deploy --network local --clear
  • you're going to see an error found by the tooling indicating there's a selector collision
• rename the function on the new contract created
• try to deploy it again: npx hardhat deploy --network local --clear
  • the error is not detected by the tooling (in fact the router is not updated) but by the solidity compiler. In order to continue working the dev should delete manually the router.

• check for duplicates via AST
• check if all selectors are reachable
• check if all selectors are present

docs: https://docs.openzeppelin.com/contracts/4.x/api/governance

v3-poc: https://github.com/Synthetixio/synthetix-v3-labs/tree/master/oz-governor

New environment could have the following structure:

deployer.deployment = {
  name: '2021-12-12-00-sirius',
  properties: autosaveObject({ ... }), // current deployment file
  abis: autosaveObject({ ... }),
  txs: autosaveObject({ ... }),
  sources: autosaveObject({ ... }),
}

Contracts

• ERC20Permit - EIP 2612 implementation, allowing tokens to approve and transfer in a single tx (with a signature) - Not really a governance thing, but super cool still.
• ERC20Votes - Token extension which keeps track of historical user balances. These balances can be used to vote at a particular block, and can even be delegated to other users.
• AccessControl - Role based access control
• TimelockController - Extension of AccessControl, that introduces a timer before any role protected actions
• Governor - Abstract and central contract for governance. It accepts, stores and executes proposals, but does not define how votes are counted, or when a proposal has consensus.
• GovernorVotes - Determines the weight that an account has when casting a vote by looking at the last snapshot for the account
• GovernorCountingSimple - For each proposal, keeps track of for and against votes. It determines when a proposal succeeds (when for > against), and when quorum has been reached (for + abstain >= quorum).
• GovernorVotesQuorumFraction - Calculates quorum as 4% of totalSupply when voting starts on a proposal.
• GovernorTimelock - Without this, a Governor can execute proposals as soon as they succeed. With this, a proposal that succeeds can only be queued for execution after the timelock period.

Experiments

• Extend current experiment with a timelock
• Multigovernance experiment - design only https://app.diagrams.net/#G11R2g_GZNiavRnLVQyUM9UztfgRI37gCn

Even though its practical to calculate paths initially, and use the results in all subtasks, it goes against the principle of making subtasks as self-sufficient as possible.

Atm, deployment aborts if it finds duplicate selectors. The problem is that this happens when the router is generated, that is after modules have been deployed.

Deploying modules can be avoided, if the check of duplicate selectors is done before.

Resources

Medium articles:
https://medium.com/element-finance/an-introduction-to-elements-governance-model-efea13d1c7ee
https://medium.com/element-finance/element-governance-a-technical-architecture-overview-2d0f72bd278a

Repos:
https://github.com/orgs/element-fi/repositories

Docs:
https://docs.element.fi/

Notes:
Can't do much more until this code is made public, which I believe should happen as soon as it's audited.

Check how major DeFi protocols enforce on-chain governance