sys design: more VP details
Gitea Actions Demo / Explore-Gitea-Actions (push) Failing after 35s Details

This commit is contained in:
Ladd Hoffman 2024-05-21 16:33:05 -05:00
parent e54339aecf
commit 30792ee479
3 changed files with 42 additions and 4 deletions

View File

@ -1,4 +1,11 @@
## DAO Core Proposals
## DAO Core
Future work may include utilizing the process defined by the Proposal contract to govern features of the core contracts themselves. When a DAO is instantiated, a specific deployment of a Proposal contract can be designated as the official core DAO Proposal contract. DAO core contracts can utilize the designated Proposal contract to create and observe proposals. This process has not yet been demonstrated, and is currently hypothetical.
### Proposals
The process defined by the Proposal contract could be used to govern features of the core contracts themselves (Bench, Forum, Reputation). When a DAO is instantiated, a specific deployment of a Proposal contract can be designated as the official core DAO Proposal contract. DAO core contracts can utilize the designated Proposal contract to create and observe proposals.
## Validation Pool
### Ratio of Minted REP Staked For/Against
The ratio of minted REP staked for and against a VP could be taken as a parameter or governed by a Proposal to increase the flexibility of the DAO.

View File

@ -11,3 +11,7 @@ flowchart TD
API <-- Matrix Client-Server Protocol\n(npm matrix-bot-sdk) --> Homeserver
```
## Contracts
### Bench

View File

@ -60,14 +60,41 @@ To achieve the Bench requirements, the contract must do the following:
1. Implement a method for initiating a Validation Pool (VP)
1. This should be a payable contract call. The value transferred is the fee for this VP.
1. The VP shall mint an amount of REP equal to `valueTransferred * mintingRatio`
1. **`mintingRatio`** may be set statically, or may be taken as a parameter when initiating a VP. Taking `mintingRatio` as a parameter enables greater flexibility, but increases overhead cost per transaction. This makes `mintingRatio` a good candidate for being governed by a Proposal process, outlined in [Future Work](./future-work.md).
1. Half of the minted REP shall be staked in favor of the VP, and the other half shall be staked against the VP.
1. This ratio could be taken as a parameter or governed by a Proposal to increase the flexibility of the DAO; see [Future Work](./future-work.md).
1. Implement a method for receiving REP stakes for/against the VP
1. Stake should be rejected if the VP `duration` has already elapsed.
1. Staking REP means that a DAO member makes an allowance for the given amount of REP to be withdrawn from their balance. The amount of the shall be recorded along with the boolean `inFavor`, but the REP is not to be withdraws from the sender's balance until certain conditions are met durint the evaluation of the VP outcome (explained below).
1. Implement a method for evaluating the outcome of a Validation Pool
1. Outcome may not be evaluated until VP `duration` has elapsed
1. An exception can be made if `totalStakedFor + totalStakedAgainst == totalSupply`. In thise case the DAO is all-in, and there's no reason to wait before evaluating the outcome.
1. The quorum is met if `(totalStakedFor + totalStakedAgainst) * quorum[denominator] >= totalSupply * quorum[numerator]`
1. The vote passes if `totalStakedFor * winRatio[denominator] >= (totalStakedFor + totalStakedAgainst) * winRatio[numerator]`
1. If the vote passes and the quorum is met,
1. If `redistributeLosingStakes` is true, then `(bindingPercent / 100) * totalStakedAgainst` shall be distributed among the accounts who staked against the VP, in proportion to their stakes.
1. The REP that was staked in favor of the VP during its initiation, shall be transferred to the Target Post, and propagated via the Forum Reference mechanism to the authors of the Post and its referenced Posts.
1. If provided, `callbackOnValidate` should be executed, and should be passed the results of the VP.
**`totalSupply`** refers to the total amount of REP held by all DAO members.
**`ValdiationPoolResult`** Fields
@ -82,7 +109,7 @@ To achieve the Bench requirements, the contract must do the following:
| Name | Type |
| --- | --- |
| `postId` | string |
| `postId` | string identifying the Target Post|
| `duration` | positive integer number of seconds |
| `quorum` | integer numerator, integer denominator |
| `winRatio` | integer numerator, integer denominator |