Celeste — a brief primer

We have been talking about Celeste and how important it is to 1hive, but there hasn’t been a good source of high level information as to what it is, how it works, and why it’s important all in one place.

What is it

Celeste is a Subjective Oracle, enabling smart contracts to ask questions and receive answers, it can be used to resolve subjective disputes, settle prediction markets, moderate content, and more by enabling developers of decentralized applications to construct and arbitrate challenge-response games.

By invoking Celeste, a developer can align incentives between parties by ensuring that it is common knowledge that defectors from an agreed upon strategy will be punished.

On a technical level, Celeste is a fork of Aragon Court, which is used for decentralized dispute resolution. The main difference between Celeste and Aragon Court, besides being on xDai and using Honey as its staking token, is that we have chosen to integrate brightID in order to limit how much stake individuals can add to the system.

How it works

In order to understand how celeste works, its helpful to first understand the general pattern of an optimistic, or challenge-response game.

Let’s say we want to create an escrow workflow for 1hive’s proposal process. Alice creates a proposal saying they will work on a project that is broken up into milestones, funds are placed into escrow and released upon request as milestones are completed. When Alice completes the first milestone, she can place a deposit as collateral in order to request the associated funds are released along with proof that the milestone was completed as expected. We can then, from a smart contract perspective, optimistically assume that Alice is honest and completed the work as expected even though the smart contract has no way to validate that the work was actually completed, so long as no one is willing to dispute the action by putting up an equal amount of collateral and block the withdrawal.

This same pattern can be used in a wide range of use cases, where there is public knowledge of what is true, but where it is not practical or simply impossible to compute that in a smart contract because the determination or judgement required is subjective in nature.

A naive solution to this problem is to just have people vote when there is a need to provide subjective information to a smart contract. But having everyone participate in a vote every time would be incredibly inefficient, what we want to do instead is to create a system where the first person interacting has a strong incentive to provide the contract with the proper information, and a sufficient disincentive to provide incorrect information.

Coming back to the example of escrow, when Alice makes the request to withdraw funds and attests that she has completed the work, Bob observes the request and determines that the proof that Alice has provided is insufficient, and chooses to challenge the withdrawal by putting up collateral and offering Alice the opportunity to withdraw their request or to add additional collateral in order to escalate and resolve the dispute by invoking Celeste.

In most cases there won’t be any need for disputes, the fact that the disputes can be escalated will be enough in most cases to ensure that participants act honestly, but in the event that there is a dispute, participants who have staked honey in Celeste will be drafted to provide a resolution.

The protocol selects participants (keepers) to evaluate a dispute and provide a resolution. They are selected proportionally to amount of honey they have staked. We assume that the majority of drafted participants will provide the correct result, but allow anyone to appeal this decision to a larger group of keepers, until we reach a final appeal round where all actively staked keepers can participate in the resolution. As things are appealed the cost in terms of both time, capital, and attention increases, and as it does we can also expect the precedent set by the decision to have a greater impact and either build or erode significant trust in the mechanism as a whole. Essentially the process is designed to minimize the need to create disputes and to resolve disputes with minimal need for escalation, but as disputes do get escalated the the incentive to provide the most appropriate response is amplified.

By incorporating brightID in Celeste we improve upon purely stake based incentives by ensuring that influence over outcomes are broadly distributed and represent a greater number of unique perspectives in the eventual outcomes, making the mechanism more resilient to attacks and making the subjective resolutions more legitimate.

Why its important

There are a bunch of new and interesting opportunities that can be built on Celeste, we can use it to settle prediction markets, create escrow type workflows, curate and categorize tokens on honeyswap, and even help validate computation that happens off-chain.

However, the most important initial use case for 1hive is integrating celeste with conviction voting mechanism that we use to distribute honey, so that we can enable the community to dispute and block proposals that may have sufficient support to execute but which do not align with the expections of the community defined in the community covenant.

Additionally, from a purely economic perspective, Celeste is really valuable to 1hive for two reasons.

  1. People will need to stake honey to participate as a keeper, and pay fees in honey in order to create and appeal disputes. As demand to use celeste increases, we will see demand to buy and hold honey increase.
  2. Because we are limiting the amount of honey individuals can stake in Celeste, we can expect that by promoting adoption of Celeste we will see the gini-coefficient of Honey decrease resulting in a more resilient and decentralized community.

When will it be ready

Celeste has been under active development for some time. There is still lots to do, but we expect to be able to launch Celeste and upgrade the 1hive DAO so that conviction proposals and decisions can be disputed before the end of the year. Keep an eye on the Celeste swarm in discord if you’d like to get involved or follow progress, we should have additional progress, updates, and roll out plans to share over the coming weeks. :sun_with_face::sun_with_face::sun_with_face:


Always a pleasure to read your post! Great ELI5. :honeybee:


Very impressive, doing great work. HNY will growth as I believe always


I’m excited for this to be ready, keep up the good work!

1 Like

I am so excited for celeste, i can’t wait for it to be out. It so aligns with the cybernetic organism narrative, i can only wish we get to build more algorithmic software products in the future for 1Hive to further minimize human intervention.

I can’t help but notice some contradiction here.
From what you said about celeste so far, my understanding is that it needs validation from participants(humans) to help it in instances where “determination or judgement required is subjective in nature”. Now since we are going to be using this in conviction voting where proposals with enough support in HNY pass, is it not obvious that anyone disputing such proposals will lose? I mean proposals that are going to be disputed are going to be proposals that have a high tendency to pass in the first place, and for such proposals to pass it has to be either supported by a majority of people so that the staked HNY adds up or a few people with huge HNY stakes. Now since keepers are human it is highly likely some of them will be in support of the proposal in question and might have even staked HNY in support of it. This is especially true when you consider that only a handful of community members show interest in voting and governance.
My point is that any proposal that is likely to pass via conviction voting when disputed and celeste invoked will still pass since it is still humans/participants with HNY that get to decide. Especially considering how keepers are selected and how the processes with further escalation which is advantageous to large HNY holders. Not saying its bad, just pointng out a flaw here.
Unless there is something i’m missing, my understanding of celeste is severely lmited at the moment anyway.

For a breakdown of the user flow, and specifically of the above process, see: Disputable Honey Pot, Celeste and Agreement User Process


Even if Celeste was purely stake based, and came down to a majority vote of honey holders, it would still be a pretty significant improvement as it would help ensure that controversial proposals had a greater amount of time and attention paid to them before they could were executed.

But I think reality is significantly different than just humans with lots of honey decide:

  1. It doesn’t require a majority of honey holders to pass a conviction proposals, it requires just 2% of honey actively being used in proposals, so there are many instances where proposals may be passed even though a majority wouldn’t support them.
  2. Celeste limits the stake an individual can add to the system, so while you still need honey to participate, having a majority of honey doesn’t allow you to control the outcome of celeste. With the limitation on stake it is effectively 1 person (with some minimum threshold of skin in the game), 1 vote. This helps balance the power of individuals and stakeholders because it gives power to stake weight (conviction voting) that can be blocked by a more democratic process (celeste).

Participation in celeste will be rewarded, initially from the common pool, but also from dispute fees. Dispute fees will be low initially, but as Celeste becomes integrated in more applications and workflows this could result in significant revenue for participants.

So while pro-active participation in governance may continue to only be attractive to a handful of highly engaged members, Celeste will encourage a broader set of participants that don’t want to participate pro-actively, but which are willing to participate when they are drafted to (and rewarded for their trouble).


What i’m saying is that the same people that voted in support of a proposal being disputed are likely to be the same people that are going to decide the outcome of the dispute. But yeah, celeste is much more democratic, plus its incentivization model might attract neutral parties that otherwise would have no interest in governance, this will inject more neutrality in the system if this group of people will be made to be active. Celeste will also be really helpful in checking large holders from passing unpopular proposals which is good for the DAO’s image. Because already it is becoming a soft target for detractors.


My main concern reading this was jurors showing up when needed. Good to hear they’re being paid, but what happens if they don’t show up, like IRL most of the time? Are they punished? What about simply busy people that may not see that they were called? Are there notifications? How long do jurors have to show up?


This is a very interesting experiment. I look forward to seeing it be battel tested and will definitely be willing to put some HNY up to be a “juror”. What is the current proposed max amount?

Sorry for the slow reply on this, it got buried in and didn’t see it till the next reply.

There is a portion of their stake that gets slashed in the event that they don’t show up or if they don’t vote coherently (with the majority). This is intended to ensure that people actually review the case and make an effort to rule coherently as opposed to not showing up or just voting randomly.

There will be an optional email notification service that we plan on running, and since the data is all on-chain other notification services could be set up either by the user themselves or by a third party.

There are several different periods where actions are required, and we can configure them, the tradeoff being time for participants to get notified, review the details of the dispute, and then make a decision, versus, the desire to have a resolution in a relatively expedient manner. Its likely that each round will take approximately a week, and participants will have ~48 hours to respond to a notification, review the details, and lock in a response.


Thanks for the explanation. Sounds like you’ve got it all figured out. Looking forward to launch

on the note of “voting coherently” why does that mean that they must adhere to what the majority chooses? I feel like that would make people doublethink and choose the option they believe most people will pick as opposed to picking the thing they believe is just. Also is the tally of current votes public knowledge during the voting period, because then people will just choose the option that is already winning and forgo actually judging the issue on the information provided.

Would it be possible to apply some of the conviction voting mechanisms here? So if you really believe an issue should be settled a particular way then you can throw some extra stake behind your vote?

Its definitely an important concern, in a sense it is a Keynesian Beauty Contest, which is generally not a good thing, but helps to address the issue of randomly voting to get rewards. And since you have limited information about other participants the best signal about how they will vote is how the system has resolved past disputes, effectively reinforcing precedence. In a sense convergence towards what everyone expect the outcome to be makes the system more predictable.

Voting is done using a commit-reveal process, so you cannot see how others have voted in the current round until everyone has already committed their vote.

I don’t think conviction voting would fit well in this context, but you can appeal decisions by staking/betting on the outcome you think will ultimately get chosen. You may find the documentation on the dispute lifecycle for Aragon Court which Celeste is based on helpful: https://help.aragon.org/article/43-dispute-lifecycle


For other projects that may use Celeste (Like the TE Commons :wink: ) would the initial deposit in disputable CV have to be in HNY or would it be possible to have it be in xDAI or even our own token?

The following challenges obv would be in HNY… but i’m more curious about that first deposit.

  1. To create actions (proposals, votes) the creator can pay the action collateral with the orgs token or wrapped xDAI.
  2. To challenge an action the challenger must pay whatever token was used to create the action as collateral and Honey as the Celeste fee. If the orgs token is not Honey, then the challenger must do 2 approval transactions for each of the orgs token and Honey.
  3. To dispute a challenged action, raising it to Celeste, the action creator must pay the court fees in Honey.

Whoever wins the dispute recoups the Celeste fees they paid in Honey plus both the action and challenge collateral put up in the orgs token.

1 Like

Awesome!! Thx for the quick response!

And the Action Collateral is effectively a deposit right, so if the action is not disputed, the person gets it back? (unlike in the Tollgate which send it to a vault)

Yes, if the action is executed successfully or the action creator withdraws their action they get the whole amount of the action collateral back.

1 Like

Why wrapped xDai? I think it should be 100% HNY IMO.