This is my bookmark for the Rareskills compound-v3-book.
The Fallback Extension Pattern
Before starting we need to understand what is fallback and recieve function. The following figure explains the difference between the two quite expressively.
In case you still do not understand the difference: The contract will trigger fallback() function if the msg.data is empty and if it isn't it will look for recieve() function. If the receive functions exits it executes it else it executes fallback() function.
The way it works is that we create a new contract with the remaining functions we want to add to the original contract and then we delegate the calls to the new contract. This way we can add more functions to the original contract without increasing the size of the original contract.
When we call the original contract that does not match the function signature of existing functions it will trigger fallback and delegate it to our secondary contract.
Governance Contract
Key glossary from the article:
Proposal: Every vote begins with a proposal, which was described earlier. It is always an Ethereum transaction that can be signed, I.e. it has a target address(es) and calldata(s).
To prevent proposal spam, contracts usually have some kind of a filter for who can create the proposal, usually an adddress that must hold a certain percentage of the total supply of the governance token.
Under the hood, a proposal is usually a solidity struct with some flags about its current state, the votes applied to it, and what transactions will be executed if the proposal passes.
Vote: Unsurprisingly, a vote is an ethereum transaction where the voter votes for or against a proposal. The vote is usually weighed by the amount of tokens the address held at the relevant snapshot.
Quorum: If no action could be taken unless 100% of the token holders voted, then it is very likely nothing would ever be accomplished, as the system would grind to a halt if only one token holder decided not to participate. On the other hand, if only 1% of the votes were required for an election to be valid, it would be too easy pass undesirable proposals.
For the fate of a proposal to be decided, it must reach a quorum threshold (a percentage of the total possible votes) within the voting period.
Voting period: Proposals don’t wait around indefinitely waiting for the quorum to be reached. Otherwise, the governance proposal might be executed at a time when the circumstances that prompted the proposal change. This countdown starts as soon as the proposal is created and if quorum isn’t reached within the time limit, the proposal is defeated.
Queued and Execution: If enough votes passed the quorum threshold in favor of the proposal, before the voting period expired, then the proposal is considered the have passed. For safety reasons, there is usually a time delay between when a proposal succeeds and when it actually gets executed.
Timelock: Not to be confused with the voting period, this is a delay between when a proposal has been approved and when the action is actually executed.
Consider a situation where a controversial proposal is in the governance contract, and a subset of dissenting users will withdraw liquidity if the proposal is enacted. The timelock gives them a window to leave after they see the lost the vote.
Giving users a chance to take action against unfavorable proposals incentives proposers to only include proposals that won’t cause a revolt.
General working of the governance looks like the following but can vary protocol to protocol:
