Governance (DAO)

tip

For further details, consult the contract reference for nebula-gov.

Nebula Protocol's governance is powered by decentralized consensus by voting power gained from staking Nebula Token (NEB). Governance is implemented as a smart contract possessing privileged access to NEB tokens and other core protocol contracts. The governance contract can only issue operations through user-submitted polls approved by a quorum of voting power from staked NEB tokens.

Procedure

Vote Locking

To participate in governance, you (NEB token holder) need to lock their NEB for a certain period of time you can choose. This time ranges from a week to 2 years (104 weeks). The longer you lock your NEB tokens, the more voting power you have. You can lock 1,000 NEB for a year to have a 500 NEB token voting weight or lock for 2 years to get your full NEB token voting weight..

Your voting weight gradually decreases every week as your tokens approach their lock expiry.

If you already have locked NEB tokens whose lock expires in X weeks and wish to lock more NEB tokens, then you must lock them for X or more weeks. The new lock period is taken as a weighted average of the previous lock period and new lock period, and rounded to the nearest week of time. Your voting power is calculated as linearly proportional to this new locking period (such that 104 weeks corresponds gives you full voting power as the number of NEB tokens held and this voting power decreases every week).

When the lock on your NEB tokens expires, you do not have any voting power and you can choose to withdraw your NEB tokens, or go through the vote locking process again.

Staking Rewards

Currently they are distributed proportionally to the amount of tokens staked. Voting rewards are proportional to voting power by design, and are good enough.

Implementation

We maintain a map from each user to $(A, W)$ such that $A$ refers to the total amount of Nebula Tokens locked by a user and $W$ refers to the number of weeks left in lock expiry.

Assume that every week, we decrease $W$ by $1$. Now, at any point in time, for a max lockup period, $M$ in weeks, the voting power $V$ of a user, is given by:

$V=\frac{AW}{M}$

The user may choose to lock more tokens, or choose to extend their lockup period, in which case we increment $A$ or $W$.

In the actual implementation, we store the ending block time instead of $W$. Note that $W$ can be calculated at any point of time using (ending block time - current block time)/(weekly block time).

Computing Quorum

Given that the total voting power constantly changes, it's difficult to determine what consists of a quorum when the poll ends.

For each poll, we store max_voting_power. Whenever someone casts a vote to a poll, that field is updated with the current total voting power of everyone who is staking tokens.

We maintain the total voting power of the system by using discrete week numbers. Each time someone stakes at time $T$, we pretend that they actually staked at the start of week that $T$ is in. This ensures that everybody's staking period starts and ends at the beginning of a week.

Now, we maintain an array arr, where arr[i % M] is the total voting power on week i. For example, if we were on week 10, and we stake tokens for 3 weeks, we would increment entries arr[10] to arr[13]. If we were on week 100, and we stake tokens for 100 weeks, we would increment entries arr[100] to arr[103], and then wrap around to increment up to arr[96]. We know that if it is week i, our current total voting power is arr[i % M].

Polls