DAO vote 2: Incentives, deprecate PSMs, holding PCV deposits, agEUR redeem#922
DAO vote 2: Incentives, deprecate PSMs, holding PCV deposits, agEUR redeem#922thomas-waite merged 149 commits intodevelopfrom
Conversation
8afa448 to
576ad46
Compare
There was a problem hiding this comment.
Confused as to the usage of "snapshot" here and previously, not sure what it means in this context
| /// This contract simply holds an ERC20 token, and delegate its voting power | ||
| /// to an address. The ERC20 token needs to implement a delegate(address) method. | ||
| /// @author eswak | ||
| contract DelegatorPCVDeposit is PCVDeposit { |
There was a problem hiding this comment.
Until I got to the part where the metagovernance role was used, I didn't realize this contract was for that purpose and not just a standard erc20 delegation contract. Should we change the name to reflect that this contract's purpose is to be used for metagovernance?
There was a problem hiding this comment.
I'm not sure what should change here, a comment or the artifact name ? We use "Delegator" in the name for all contracts that call erc20vote.delegate() and other than that it's a very simple pcv deposit
There was a problem hiding this comment.
Artifact name (delegating normal votes vs using for metagovernance is the confusing part)
|
|
||
| /// @title Vote-locked AURA PCVDeposit | ||
| /// @author eswak | ||
| contract VlAuraDelegatorPCVDeposit is DelegatorPCVDeposit { |
There was a problem hiding this comment.
Can you update the description of this contract to provide more context?
| IERC20 immutable token; | ||
|
|
||
| /// @notice Fei ERC20 token address | ||
| address private constant FEI = 0x956F47F50A910163D8BF957Cf5846D573E7f87CA; |
There was a problem hiding this comment.
Would prefer that we not inline this and use CoreRef instead
There was a problem hiding this comment.
This was approved and deployed in this PR: #930
There was a problem hiding this comment.
Would be nice to use CoreRef, but don't think it warrants making a change now and redeploying
| } | ||
|
|
||
| /// @notice Empty receive function to receive ETH | ||
| receive() external payable {} |
There was a problem hiding this comment.
Should add fallback as well to catch all use cases of sending eth to this contract
There was a problem hiding this comment.
What use case of sending eth to this contract would a receive() function not handle, but a fallback would?
There was a problem hiding this comment.
Fallback handles contract calls that don't match any function, receive() only handles transfers
| @@ -3,13 +3,15 @@ pragma solidity ^0.8.4; | |||
|
|
|||
| library MainnetAddresses { | |||
There was a problem hiding this comment.
Just now seeing this library - should we ensure that this is synced with the TS mainnet addresses? (via a test or something, dunno)
There was a problem hiding this comment.
I don't see the use case/additional guarantees of ensuring this is synced with the TS mainnet addresses. If there is a compelling reason, should break it out into a seperate PR
|
|
||
| before(async function () { | ||
| // Setup test environment and get contracts | ||
| const version = 1; |
There was a problem hiding this comment.
What does this version number mean?
There was a problem hiding this comment.
This has been part of our e2e harness since the beginning I think - I remember adding a version number back when I was contracting.
Down for a refactor of our e2e setup, but that should be broken out and likely done in Foundry
| } | ||
| }; | ||
|
|
||
| export type PauseState = { |
There was a problem hiding this comment.
Should change this to PSMPauseState, and this should be an interface instead of a type generally.
There was a problem hiding this comment.
I think we can keep this name generic, there's no reason we wouldn't use this to check paused state of other contracts (in addition to PSMs)
There was a problem hiding this comment.
Also think this should stay generic. It does the job that we need right now in allowing us to quickly verify pause state with a local config
| @@ -0,0 +1,30 @@ | |||
| export const pauseStateConfig: PauseStateConfig = { | |||
There was a problem hiding this comment.
I think we should rethink this test. While it's good to ensure that certain contracts are either paused or not, this config and these types are too specific to PSMs.
There was a problem hiding this comment.
We could name this in a generic way "state config" and use that to check various state variables. For instance we could add
lusdPSM: {
paused: true,
redeemPaused: true,
surplusTarget: '{bammDeposit}'
}
and other state checks
There was a problem hiding this comment.
I think I prefer this to what we have now, though still not sure if this test/config is warranted. Discuss in dev meeting perhaps?
There was a problem hiding this comment.
The initial version of this test was done to make sure we don't accidentally unpause/pause something and don't know. We'll loudly get alerted now if we do something that accidentally unpauses.
If we have need for a more thorough pause state test in the future very down for iterating and breaking out into another PR
| address: '0x45EB1A004373b1D8457134A2C04a42d69D287724', | ||
| category: AddressCategory.External | ||
| }, | ||
| eswak: { |
There was a problem hiding this comment.
I don't think we should put personal/deployer addresses in this file
There was a problem hiding this comment.
it's either this or magic addresses in proposal descriptions because for instance the DAO vote has a setDelegate(address) call that needs my address as a parameter. But I'm fine with both, added this because Tom wanted to have it in the config file
There was a problem hiding this comment.
Yep much prefer having any address that gets used in a DAO vote in mainnetAddresses under a human readable key, rather than having a magic address in the script
| let initialCoreTribeBalance: BigNumber; | ||
| let initialRariDelegatorBalance: BigNumber; | ||
|
|
||
| const EXPECTED_WETH_TRANSFER = toBN('21716293570455965978548'); |
There was a problem hiding this comment.
Please add a comment for each of these vars explaining what they mean & providing a little bit of context
There was a problem hiding this comment.
Totally, good idea. Will add
…l/fei-protocol-core into deprecate-incentives
…otocol-core into deprecate-incentives
…l/fei-protocol-core into deprecate-incentives
…otocol-core into deprecate-incentives
DAO vote 2: Incentives, deprecate PSMs, holding PCV deposits, agEUR redeem
Batches various cleanup and technical maintenance tasks into a second DAO vote:
Incentives cleanup
This proposal funds the owed outgoing incentives and then withdraws TRIBE from various areas in the system: Tribal Chief, ERC20 Dripper, Votium contracts and sends it to the Core treasury.
It also transfers the owner of the Fei Aave incentives controller from the TRIBE DAO to the Aave DAO.
Key numbers
Amount of TRIBE:
Total to be recovered: 31.3M TRIBE
Implementation
Off-chain, all staking token wrapper harvests have been performed.
The final deprecation steps performed are:
governorWithdrawTribe(uint256 amount)