Sulkta-OSS/agora
3
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

implemented changes from review

Browse source
This commit is contained in:
Jack Hodgkinson 2022-02-07 14:47:52 +00:00
parent 1bb44923ee
commit 282e7ab99f
4 changed files with 26 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/tech-design/proposals.md
View file

@ -6,7 +6,7 @@ This document gives an overview of the technical design of the proposals system
|:-----------:|:-----------:|:-------------:|
| WIP | WIP | v0.1 2022-02-02 |
***
---
**Specification ownership:** [Emily Martins]
@ -23,9 +23,9 @@ This document gives an overview of the technical design of the proposals system
**Current status**:
Imported from Liqwid by [Emily Martins]. Underwent rewrite by [Jack Hodgkinson].Further amendments to the 'period table' should be considered.
Imported from Liqwid by [Emily Martins]. Underwent rewrite by [Jack Hodgkinson].Further amendments to the 'period table' should be considered.
***
---
## Proposals
@ -51,13 +51,13 @@ Consider the following 'stages' of a proposal:
| Action | Valid POSIXTimeRange | Valid _stored_ state(s) |
|-------------------------------------|------------------------------------|-------------------------|
| Witness | \[S, ∞] | \* |
| Cosign | \[S, S + D] | Draft |
| AdvanceProposal | \[S, S + D] | Draft |
| Vote | \[S + D, S + D + V] | Voting |
| Unlock | \[S + D, ∞] | \* |
| CountVotes (? see spec comment) | \[S + D + V, S + D + V + L] | Voting |
| ExecuteProposal (if quorum reached) | \[S + D + V + L, S + D + V + L + E] | Voting |
| Witness | \[S, ∞) | \* |
| Cosign | \[S, S + D) | Draft |
| AdvanceProposal | \[S, S + D) | Draft |
| Vote | \[S + D, S + D + V) | Voting |
| Unlock | \[S + D, ∞) | \* |
| CountVotes (? see spec comment) | \[S + D + V, S + D + V + L) | Voting |
| ExecuteProposal (if quorum reached) | \[S + D + V + L, S + D + V + L + E) | Voting |
```diff
- CountVotes takes a snapshot after voting has ended, it allows users to unlock their stake without affecting votes, after the lock period has ended. This is an optional feature of locking, do we want this?
@ -67,11 +67,11 @@ Consider the following 'stages' of a proposal:
#### Draft phase
During the draft phase, the proposal script has been created. At this stage, only votes in favor of co-signing the draft are counted. For the proposal to transition to the voting phase, a threshold of GT will have to be staked backing the proposal. This threshold will be determined on a per-system basis and could itself be a 'governable' parameter.
During the draft phase, a new UTXO at the proposal script has been created. At this stage, only votes in favor of co-signing the draft are counted. For the proposal to transition to the voting phase, a threshold of GT will have to be staked backing the proposal. This threshold will be determined on a per-system basis and could itself be a 'governable' parameter.
#### Voting phase
In the voting phase, users may utilise their stakes to vote in-favour or in-opposition to a proposal. This adds their public key to the proposal. There is potential for contention within the system and therefore may have to be rate-limited. The method by which a user's stakes are weighted and the thresholds required for proposals to pass are determined on a per-protocol basis.
In the voting phase, users may utilise their stakes to vote in-favour or in-opposition to a proposal. This will add their vote to the relevant count. There is potential for contention within the system and therefore voting on proposals may have to be rate-limited. The method by which a user's stakes are weighted and the thresholds required for proposals to pass are determined on a per-protocol basis.
#### Lock phase
@ -79,7 +79,7 @@ Upon completion of the voting phase, a proposal will either have been passed or
#### Execution phase
Failed proposals will not be interacted with further. The only value they will contain is their state thread tokens, so nothing of worth is lost.
Failed proposals will not be interacted with further. The only value they will contain is their state thread tokens and the minimum ADA requirement, so little of worth is lost.
Successful proposals will be verified by the governor component, which will issue ['governance authority tokens'](/docs/tech-design/authority-tokens.md) (GATs) to a proposal's separate 'effects'. The burning of these tokens will be a pre-requisite for system changes to be made, therefore the possession of one will serve as a form of 'licence' for making the changes.