Staking and voting
Lock $ORBU for vote weight. No yield, no reward and no fee share, ever. The council contract cannot pay any of them: it has no call that sends a token to anyone but the staker who locked it.
Locking
One locked token is one vote. lock(amount, unlockAt) credits what actually arrived. The unlock date can only stay or move later. withdraw(amount) works for the staker alone, only after their lock, and no proposal can hold it back.
A proposal's life
Weight comes from before the second the proposal opened, so tokens locked later count for nothing in it. Your vote counts the smaller of that weight and what you still have locked, and your lock must last through the vote and the timelock, so you stay locked until the outcome can apply. A proposal passes with at least the quorum in yes votes and more yes than no; a tie fails. No votes do not count toward the quorum, so an unopposed proposal passes on the quorum alone: 2% of a 1B supply. Once a newer proposal has applied to a value or a roster entry, an older one on the same thing is refused. A wallet can open one proposal per voting period.
What an outcome can do
- Record a note, with no effect.
- Add an entry to the module list.
- Retire an entry, or list it again.
- Set a named signal value, which the site can use as a default.
That is the full list. There is no generic call, so an outcome cannot reach a balance, a signed order or the desk. New desk behaviour would need a new desk, deployed separately, and it could not move anything without its own approvals.
Parameters
| Voting period | 3 days |
|---|---|
| Timelock | 2 days |
| Lock length | 7 to 365 days |
| Quorum, yes votes | 20,000,000 $ORBU |
| To open a proposal | 100,000 $ORBU |
Set in the constructor and immutable. These are the values prepared for deployment; check them on chain before relying on them.
