Deployment of Honey Pot and Celeste Contracts

To update the Honey Pot to integrate with Celeste we have opted to redeploy the entire 1Hive Protocol. This involves deploying a new Aragon DAO in 2 steps between which we will deploy Celeste. This is because the Aragon DAO depends upon Celeste, to allow disputable decisions and proposals, and Celeste depends upon the Aragon DAO, to integrate BrightId. Once the 1Hive Protocol is redeployed, although users will be able to create proposals there will be 0 Honey in the Common Pool and it won’t be able to issue any. In order to allow the new 1Hive Protocol to mint new Honey we must transfer the Honey’s token controller from the old 1Hive Protocol to the new 1Hive Protocol. We must also transfer the current balance of Honey into the new 1Hive Protocol. This will require a decision vote that will take 16 days to execute (14 days voting period and a 2 day execution delay).

Any double checking of the following configuration would really help us ensure the deployment is accurate. If you have the time and the interest feel free to help out by checking the following.

The config used for the 1Hive Protocol deployment.

The config used for the Celeste deployment to xDai.

The script that will be used to create the vote script which will transfer the funds and current token controller to the new 1Hive Protocol.

The template contract used to deploy the DAO

I have deployed the 1Hive Protocol as above and created the vote to transfer most of the current common pool’s funds and token controller to the new 1Hive Protocol. If between now and QA being finalised on the UI changes need to be made to the contracts, I will update them, redeploy and create a new vote. In the mean time I don’t suggest anyone vote on the votes created until we are sure they won’t break anything but since they will take 16 days to process we want to have them prepared once we’re ready. Voting in favour of these votes will lock your Honey until the vote is finalised.

The currently deployed DAO addresses.

UML diagram of the current permissions generated using the currently deployed DAO.

The current vote can be seen in the Honey Pot although unfortunately the description isn’t present. It can also be seen in the Aragon Client where there is a better description.

All vote creation transactions cost 5 Honey each which will require reimbursement in future, I will add all vote creation transactions here as a record:
Vote 1 transaction
Vote 2 transaction created because the first vote will fail, didn’t grant permission to voting to transfer vault funds but it attempts to transfer vault funds.
Vote 3 transaction submitted about a week after the previous vote to delay launch should we need to.
Vote 4 transaction submitted another week later after previous to delay launch.
Vote 5 transaction To transfer the remaining Vault Honey to the new DAO.


Very cool! I am glad to see that you’ve got the ball moving on this @willjgriff. I have been doing some testing on Celeste, and despite a few little hiccups I think this is a great initiative.


I would be happy to help but this is dark magic to me.
Good luck! Fingers crossed.

1 Like

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:

  1. 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.
  2. 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.


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.


Great work to you and the team!

This is pretty epic! This really helped me understand how an Aragon DAO is built. I still feel like I have a whole lot more to learn.

I think it would be cool to have a video on the 1Hive YouTube channel walking people through how 1Hive’a Aragon instance was conceived and implemented.

I would also be curious if you have any resources on building a DAO in general, from philosophy to construction to launch. Any materials would be appreciated. :pray:t4:

1 Like

Perhaps we can do a weekly drop in call on that topic and just record it, Discord has a new “stage” channel feature that would be good for podcast/interview style calls that we could use. We could record it and post it on YouTube.


Yeah that would be awesome, and I think it would be super helpful especially for new comers. Shall we pick a day this week and just do it? Maybe Friday?

Nice gonna vote it after the honeyswap analytics page repair payment for hernandoagf is passed

What would be the best way to get the ball rolling on this?

Lets chat on discord and find a time that works and put it in the 1hive calendar :smiley:

Amazing write up thanks Luke, you have a gift with explaining technical things in an easy to understand manner. Have voted in support

I reviewed the BrightIDRegister app contract with its settings and followed @lkngtn 's process for checking the vote and then voted yes. Glad to see it has 13% (of 10% required). If I understand, our votes are locked, so this vote can’t fail at this point unless new no votes are cast totaling more than the yes votes. Is that true?

1 Like

Thanks for checking out the BrightIdRegister app. If you have any thoughts I’d be interested to hear them.

Yeah the vote will pass now unless at least another 13% of HNY holders vote against it.

1 Like