Honey + Celeste Upgrade âDecisionâ
In order to upgrade Honey to the new version that is integrated with Celeste will has created a Decision Vote to enact the upgrades. Here is what we are upgrading:
- We are migrating the Honey token to a new Token Manager in a new Aragon DAO, this new Aragon DAO has the new Dynamic Issuance Policy, Disputable Conviction Voting, and Disputable Voting.
- We are transferring the Honey in the common pool into the common pool in the new DAO.
This is a really important upgrade for 1Hive and we want to make sure it goes smoothly and everyone has an opportunity to understand and verify what the vote will do, so going to walk through the process I used to confirm what the vote does.
First lets find the vote in the honeypot interface. Youâll notice that the description of the vote isnât as informative as we would like, these descriptions are generated automatically by looking at the contracts and decoding them using radspec. However, in this case there seems to be frontend bug preventing it from pulling the description properly (this may be fixed by the time you read this this, but if not you can do what I did, and look it up in the Aragon Client.
Youâll see a more full description there, and can click on addresses to verify them.
To help parse this description lets break it up into specific actions.
1. âTokens (HNY): Change the token controller to `0xEd062e26c8F41a9088d060156eDC7fc6c17d5825`â
2. âACL: Grants âVotingâ the ability to perform actions of role `0x8502233096d909befbda0999bb8ea2f3a6be3c138b9fbf003752a4c8bce86f6c`on âVaultââ
3. âVault: Transfer 8790000000000000000000 `0x71850b7E9Ee3f13Ab46d67167341E4bDc905Eef9` from the Vault to `0x4ba7362F9189572CbB1216819a45aba0d0B2D1CB`
The first step is saying itâs going to change the token controller of Honey to the new token manager. We can open the âNewâ 1hive DAO in the Aragon Client, in order to confirm that 0xEd062e26c8F41a9088d060156eDC7fc6c17d5825 corresponds to the new Token Manager App. If you click on the âTokensâ app in the new DAO, you should see the same address in the URL. (It will be the second address in the url, the first references the new DAOs kernel).
So that lines up with our expectation and the first step seems to be doing what we want. The second step is granting the Voting app a permission on the vault. This is the âTransfer_Roleâ which is currently only assigned to the Conviction Voting app, but radspec gives us the role name hash. To verify that this is the transfer role, we can look at the vault on block scout using âread proxyâ. We can then compare the TRANSFER_ROLE variable with the radspec description to confirm.
So again, this appears to be doing what we would expect it to do, we need the voting app to have the transfer role so that the third action will complete successfully. The third action is just transferring Honey from the current common pool to the new common pool. Radspec gives us the raw amount, so we need to shift by 18 decimals to get the actual amount, which would be 8790, this is a bit less than the current balance of the common pool due to issuance, but thatâs good since if it was higher (due to proposals passing since the vote started, the whole transaction would fail). This will leave a couple hundred honey in the common pool, which we will need to create a subsequent vote to move over, though its not super urgent as issuance will no longer work on the old DAO after this vote passes (since the old issuance app wonât have permission on the new token controller).
Thats it in terms of what the vote is doing, but its also important for us to review the new DAO is configured as we expect, otherwise we will be irreversibly be transferring the HNY token to a DAO that may be bricked/misconfigured in some way. So lets take a lookâŠ
Starting on the first page of permissions we can see disputable voting is the manager of everything, which is good, disputable voting replaces dandelion voting in the new DAO and is the new âdecisionâ process.
We also see the Agent which replaces the vault (and is the new common pool address), allows conviction voting to move tokens. The agent also allows executing actions on external contracts, and this is granted to the disputable voting app, this will allow us to give permissions over external contracts to the DAO more effectively.
The Agreement app is the interface between the Aragon DAO and Celeste, it can be upgraded via disputable voting.
The Brightid Register app is what we use to check brightid Verifications on-chain (eg for Celeste) and it can be updated via disputable voting.
Conviction voting settings can be configured via disputable voting (decisions), and anyone can create or challenge proposals. Conviction voting also has a pause function, which has been granted to the Bug Bounty swarm, so that it can pause the contract in the event a bug is found, but it cannot change the configuration settings or do anything else without requiring a full vote.
On page two of the permissions, we have the âset agreementâ role for conviction voting set to the agreement. This has to do with how disputable apps interact with the agreement and celeste, and appears to be correctly configured.
Then we have a bunch of permissions related to Disputable Voting parameters which can be adjusted. And like conviction voting anyone can create or challenge proposals. Will come back and take a closer look at how disputable voting is configured, because if it is configured properly, it should allow us to use a vote it should allow us to fix/adjust pretty much anything else.
We also can see the âupdate settingsâ permission on the new issuance app that manages the dynamic issuance policy. This is granted to disputable voting.
And finally on the last page, we have the mint and burn permissions on the token controller granted to the issuance app.
If we go over to the systems permissions tab:
We can see that all the system permissions are granted to disputable voting as well. So essentially if disputable voting is working properly, we should be in reasonably good shape to be able to correct from there.
So far this is looking good, in terms of how permissions are assigned, but we also need to verify important parameters have been set, specifically worried about disputable voting, as its possible that it was using a different token or has a quorum or support setting which would prevent us from passing votes, so lets take a look at that on block scout.
We can see on â38â, that the configured token is HNY: 0x71850b7e9ee3f13ab46d67167341e4bdc905eef9
And we can see the settings:
The first value is the vote duration in seconds, which is set to 5 days. Shorter than the current decision voting period, but still long enough that there is time for people to engage with the votes.
The next two are support required percentage, and min acceptance quorum (what percent needs to vote yes out of the whole supply for the vote to valid). Both use 1000000000000000000 as the PCT_BASE, so the first one is 500000000000000000/1000000000000000000 or 50% and the second is 100000000000000000/1000000000000000000 or 10%. Ten percent is a lot, and will make passing votes difficult⊠we may want to lower this in the future, but it matches what we currently are using in dandelion voting, so if we manage to pass that one, we should be able to pass these as well.
The remaining settings related to different periods in the voting process in seconds, and all appear to be sane values.
Voting
Once you are satisfied, and feel free to ask questions and dig deeper, the more eyes closely examining this the better! You can cast your vote (we need to hit 10% yes for it to be valid). Keep in mind that once you vote yes your entire balance of HNY will be locked and non-transferrable until the vote ends. So keep this in mind, and consider waiting till near the end of the vote if you want to minimize the lock time.
