EGP-27: Removal of Non-Contributor Grants from the Vesting Vault

EGP#: 27
Title: Removal of Non-Contributor Grants from the Vesting Vault
Author(s): DELV
Type: Protocol Proposal
Status: Proposed
Date Proposed: 2023-10-03
Date Ratified: <yyyy-mm-dd>

References

• Element DAO, ELFI Voting Distribution: https://mirror.xyz/0x3fcAf7DDf64E6e109B1e2A5CC17875D4a5993F39/bctuLRkf7oBL4mMJ9lPf0y0blFjBDslTUfUL0CEk1gc
• Vesting Vault Documentation: https://docs.element.fi/governance-council/council-protocol-smart-contracts/voting-vaults/vesting-vault
• Vesting Vault Contract: https://github.com/element-fi/council/blob/main/contracts/vaults/VestingVault.sol
• Deployed Vesting Vault Contract: https://etherscan.io/address/0x716D4e863536aC862AD34bC4eCaCBa07d8831bEA#readContract

Sentence Summary

EGP-27 is being proposed to remove the DELV (formerly Element Finance) team-allocated token grants for those who left DELV before their vesting cliffs, reduce existing grants for Team Members who partially vested, or for Team Members who left before the vesting dates were reached.

Paragraph Summary

This proposal formalizes a solution for the removal/reclaiming of DELV Team Members-allocated token grants who departed prior to reaching the vesting vault smart contract-defined vesting cliffs, partially vested, and/or before the vesting dates were reached.

These DELV team-allocated token grants were distributed during the governance launch of Element DAO on March 31 of 2022. The vesting cliff was defined as one year from the launch date and the token vesting schedule defined was as three years after the launch date.

Motivation

The purpose of this EGP is to regain the unvested token allocations that were given to previously employed DELV Team Members, allowing DELV to be able to award new token grants to new employees and contributors.

Important note: DELV will place this proposal on chain (if it reaches that stage of governance), but neither DELV nor DELV Team Members will vote on this proposal. Furthermore, DELV engineers will provide purely technical comments only; they will not provide any statements on the wisdom or appropriateness of the proposal.

Specification

The VestingVault contract holds grants for various holders of the ELFI governance token. For reasons stated in the Motivation section, some grants need to be adjusted. This adjustment takes the form of updating two variables: allocation and range. allocation is what it sounds like, the number of tokens awarded after the grants vest. range refers to the specific token range to which the grants apply. As the allocations are reduced, the ranges need to be updated as well. If there is no range specified, it is left unspecified. Furthermore, as allocations are reduced, we update the unassigned value by the amount the allocation is reduced. This proposal makes no assumption about the future use of the now unassigned tokens in the VestingVault will be used.

Proposed Code

As a part of this proposal, a contract will be used to perform the necessary modifications to existing token grants. This contract can be viewed here: https://github.com/sentilesdal/council/contracts/vaults/UnfrozenVestingVault.sol

Only the method that will be called is reduceGrant().

Scripts in the above-mentioned repository will be used to deploy the upgraded contract and create and execute the proposal.

The basic idea of the proposal is that, from the Timelock contract, the following three actions will be performed on the VestingVault:

1. Upgrade the proxy implementation of the VestingVault.
2. Update allocation to the new amount. If the new value is zero, delete the grant. If a range is specified, update that value as well.
3. Reset the proxy implementation of the VestingVault.

You can see the proposed values here for the creation of the proposal, assuming the proposer uses only the locking vault to satisfy the minimum voting power threshold to create the proposal.

{
 "proposalId": 11,
 "votingVaults": [
  "0x02Bd4A3b1b95b01F2Aa61655415A5d3EAAcaafdD"
 ],
 "extraVaultData": [
  "0x00"
 ],
 "targets": [
  "0x81758f3361A769016eae4844072FA6d7f828a651"
 ],
 "callDatas": [
  "0x88b49b8392069f208fc38d865c56166ac46dac5702d41e4551bb4462de2765023ad68dd5"
 ],
 "proposalHash": "0x5ee0fd08dadf12291e94d59a9ab3310e004ccde3ec967b84855921cbc55ddfb1",
 // all targets are the VestingVault proxy contract.
 "targetsTimeLock": [
  "0x6De73946eab234F1EE61256F10067D713aF0e37A",
  "0x6De73946eab234F1EE61256F10067D713aF0e37A",
  "0x6De73946eab234F1EE61256F10067D713aF0e37A",
  "0x6De73946eab234F1EE61256F10067D713aF0e37A",
  "0x6De73946eab234F1EE61256F10067D713aF0e37A",
  "0x6De73946eab234F1EE61256F10067D713aF0e37A",
  "0x6De73946eab234F1EE61256F10067D713aF0e37A"
 ],
 // function signatures are upgradeProxy,reduceGrant[],upgradeProxy
 "calldatasTimeLock": [
  "0x74474d2800000000000000000000000038dbc89fc52948192843920e78c8b609474b60b4",
  "0xf9c251a7000000000000000000000000fb18b8f2bbe88c4c29ca5a12ee404db4d640fe4e000000000000000000000000000000000000000000000c5e76e895786ec80000",
  "0xf9c251a70000000000000000000000004103672489e420076b012dda2ba2b0c414d985ca000000000000000000000000000000000000000000008c79d8ff876c616c0000",
  "0xf9c251a7000000000000000000000000fb0e31b422e606ca996e4415243ebf15c2e5535e0000000000000000000000000000000000000000000006eb1c65b9679d730000",
  "0xf9c251a700000000000000000000000084ad922d23a7613e0d25f36cb65cd5f92a155110000000000000000000000000000000000000000000041e6305ae73f1619b0000",
  "0xf9c251a7000000000000000000000000e68e82c3c49df3d9c8b04b0bb8e5f1cdc28dae520000000000000000000000000000000000000000000000000000000000000000",
  "0x74474d28000000000000000000000000716d4e863536ac862ad34bc4ecacba07d8831bea"
 ],
 "callHashTimelock": "0x92069f208fc38d865c56166ac46dac5702d41e4551bb4462de2765023ad68dd5",
 // TBD, will actually be 2 weeks from on chain creation.
 "lastCall": 18572742,
 "ballot": "2"
}

Test Cases

The code will be dry-run using Ethereum mainnet forks. Values will be inspected to make sure that they make sense and yield the intended results.

The following should be true AFTER the proposal is executed:

• All the targeted grants have expected allocations
• All targeted grants with range values have updated the range as expected
• Allocations that are now zero are deleted from storage
• NO other values should change except allocation and range

Security Considerations

• There are several security considerations with this proposal. Most importantly, this proposal will make changes to existing token grants in the vesting vault and is therefore very sensitive. Extra care should be taken to make sure that updated values in the created proposal align with intentions.
• The other security concern is with the smart contract used to perform the modifications to the token grants. This contract should go under audit and review to ensure that it only performs the desired changes to the smart contract and that it has no unintended consequences.

Technical Review Plan or Audit Information (If already available)

The code for this proposal is publicly available for the community to review at https://github.com/sentilesdal/council. Engineers at DELV have conducted internal reviews of both the smart contract updates and the code used to generate the proposal. After the proposal is made public, there should be ample time to allow the community to audit the code.

Next Steps (Voting Outcome Summary)

1. This proposal is currently a Draft.
   1. We welcome all questions and comments over the next week, but please be advised that DELV Team Members will not be able to provide comments beyond formatting and technical commentary.
2. Once the feedback has been addressed, this will move to be officially Proposed.
3. Once Proposed, there will be a 1 week review period before it moves to the next stage, Off-Chain Poll (Snapshot).
4. On Snapshot, the governance community will vote for:
   1. Yes: You agree that the token grants for departed DELV team members should be removed/reclaimed.
   2. No: You disagree that the token grants for departed DELV team members should be removed/reclaimed.
   3. Abstain: formally decline to vote either YES or NO.
5. If this proposal passes the Off-Chain Poll, it will proceed to the On-chain Vote, where the vote options will remain the same as on Snapshot.
6. If this proposal passes, the proposal will officially be Accepted and the code will proceed to the Execution stage where the previously allocated token grants will be removed/reclaimed.