-
Notifications
You must be signed in to change notification settings - Fork 78
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #58 from anoma/bengt/pgf-specs-update
Update specs for pgf
- Loading branch information
Showing
7 changed files
with
138 additions
and
73 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
89 changes: 59 additions & 30 deletions
89
packages/specs/pages/economics/public-goods-funding/funding.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,53 +1,82 @@ | ||
import { Callout } from 'nextra-theme-docs' | ||
|
||
# Mechanism | ||
# Mechanism of funding | ||
|
||
Once elected and instantiated, PGF stewards will then unilaterally be able to sign transactions that propose either RPGF or CPGF funding. The PGF stewards as a whole will have an "allowance" to spend up to the `PGF` internal address's balance. | ||
Once elected and instantiated, PGF stewards will then unilaterally be able to sign transactions that propose either RPGF or CPGF funding. The PGF funding proposals in joint may spend up to the `PGF` internal address's balance. | ||
There is also the ability for non-stewards to propose funding, but the voting conditions are different. | ||
|
||
## Proposing Funding | ||
In order to propose funding, any steward will be able to propose a PGFProposal through governance. Only stewards will be valid authors of these proposals. There will be a minimum voting period set specifically for these types of proposals and can be changed by Governance. | ||
## Proposing funding as a PGF steward | ||
In order to propose funding, any steward will be able to propose a `StewardFundingProposal` through governance, which is a custom proposal. | ||
Only stewards will be valid authors of these proposals. There will be a minimum voting period set specifically for these types of proposals and can be changed by Governance. | ||
|
||
This governance proposal will be such that it **passes** by default **unless** the following conditions are met: | ||
This governance proposal will be such that it **passes** by default **unless** the proposal is ***vetoed***. | ||
|
||
Conditions to veto a PGF proposal: | ||
##### Conditions to veto a `StewardFundingProposal`: | ||
1. Out of the votes that voted for the proposal, more than $50\%$ voted `Nay` on the proposal | ||
2. At least $\frac{1}{3}$ of voting power voted on the proposal. | ||
- Further, if at least $\frac{2}{3}$ of voting power voted `Nay` on the proposal, and the proposal was rejected, the Steward is removed from the set of stewards. | ||
|
||
### Structuring the proposal | ||
|
||
The PGF stewards should be able to propose both retroactive and continuous public funding transactions. Retroactive public funding transactions are straightforward and implement no additional logic to a normal transfer. | ||
|
||
However, for continuous PGF (cPGF), the stewards should be able to submit a one time transaction which indicates the recipient addresses that should be eligble for receiveing cPGF. | ||
|
||
The following data is attached to the PGF transaction and will allow the stewards to represent the projects they wish to be continously funded. Each tuple represent the address of the recipient and the respective amount of NAM that the recipient will receive every epoch. | ||
#### Retroactive PGF (RPGF) | ||
The PGF stewards should be able to propose both retroactive and continuous public funding transactions. | ||
Retroactive public goods funding (RPGF) transactions are straightforward and implement no additional logic to a normal transfer. | ||
The following data is attached to the PGF transaction and will allow the stewards to represent the projects they wish to be funded retroactively. | ||
Each tuple represent the address of the recipient and the respective amount of NAM that the recipient will receive. | ||
|
||
```rust | ||
struct cPgfRecipients { | ||
struct RPgfRecipients { | ||
recipients: HashSet<(Address, u64)> | ||
} | ||
``` | ||
The mechanism for these transfers will be implemented in `finalize-block.rs`, which will send the addresses their respective amounts each end-of-epoch. | ||
Further, the following transactions: | ||
- add (recipient, amount) to cPgfRecipients (inserts the pair into the hashset above) | ||
- remove recipient from cPgfRecipients (removes the address and corresponding amount pair from the hashset above) | ||
should be added in order to ease the management of cPGF recipients. | ||
|
||
```rust | ||
impl addRecipient for cPgfRecipients | ||
#### Continuous PGF (CPGF) | ||
However, for continuous public goods funding (CPGF), the stewards will need to propose ***changes*** to the current set of CPGF recipients and amounts they receive. | ||
We define the **set** of tuples representing the (address of the CPGF recipient, amount of NAM received per epoch) as the `CPgfSet`. | ||
We refer to the individual tuple as a `CPgfEntry`. | ||
|
||
impl remRecipient for cPgfRecipients | ||
In this manner, any steward can propose a vector of ***deltas*** to the current `CPgfEntry`s in the `CPgfSet`. | ||
These deltas will be attached to the `StewardFundingProposal` as follows: | ||
|
||
```rust | ||
struct CPgfDeltas { | ||
deltas: Vec<(Address, i64)> | ||
} | ||
``` | ||
|
||
## PGF stewards incentives | ||
<Callout type="info"> | ||
Note that the amount of NAM received per epoch is represented as an `i64`. This means all deltas must be integers. | ||
However, the amount of NAM received per epoch is represented as a `u64` in the `CPgfEntry`, which means that large negative deltas act as a removal of the recipient from the set. | ||
</Callout> | ||
|
||
##### Applying deltas to the `CPgfSet` | ||
The `CPgfDeltas` will be used to update the `CPgfSet` as follows: | ||
|
||
- If the address is not in the `CPgfSet`, then the address is added to the `CPgfSet` with the corresponding amount. | ||
- If the address is in the `CPgfSet`, then the amount is updated by adding the delta to the current amount. | ||
- If the delta is negative and the current amount is less than (or equal to) the absolute value of the delta, then the address is removed from the `CPgfSet`. | ||
|
||
##### Mechanism of CPGF | ||
The mechanism for these transfers will be implemented in `finalize-block.rs`, which will send the addresses their respective amounts each end-of-epoch. | ||
|
||
###### Edgecase: Total amount of NAM sent to `CPgfSet` is greater than the total amount of NAM in the PGF internal address | ||
Because the amount in each `CPgfEntry` is not verified, and the absolute value of the PGF internal addresses is unpredictable, it may occur that the total amount of NAM sent to the `CPgfSet` in one epoch is greater than the total amount of NAM in the PGF internal address. | ||
In this case, the PGF internal address will be set to zero, and the `CPgfSet` will be receive funding accordingly: | ||
|
||
The total sum of amounts in the `CPgfSet` will be calculated, and the the amount of NAM transferred to a single `CPgfEntry` will be proportional to the amount of NAM in the `CPgfEntry` relative to the total sum of amounts in the `CPgfSet`. | ||
More accurately, it will be calculated as follows: | ||
|
||
$$T:= \sum_{\text{Entry} \in \text{CPgfSet}} {\text{Entry.amount}}$$ | ||
|
||
$$\textit{Transfer to entry} \leftarrow \text{Entry.amount} \cdot \frac{\text{PGFInternalAddress.balance}}{T}$$ | ||
|
||
|
||
Being a PGF steward is (should be) hard work. Stewards must invest their time in crafting proposals, being in touch with the opinions of the Namada community, and taking the risks associated with being voted out. | ||
In order to incentivise this effort, Namada allocates a set amount of NAM inflation that is directed towards the stewards. | ||
## Proposing funding as a non-PGF steward | ||
|
||
This inflation is allocated towards the PGF internal address, in which each steward account has control over their respective share of the funds. | ||
The inflation is "streamed" to the PGF internal address, in an identical manner to how the cPGF is streamed to the recipients (i.e end of each epoch). | ||
The Steward account can then unilaterally (within the rules of a multisig transaction) either: | ||
- Set up a "stream of income" to another account (e.g a personal account) | ||
- Transfer collected funds in a lump sum transaction | ||
There is also the possibility to propose funding as a non-PGF steward. This is done by submitting the custom governance proposal `FundingProposal` through governance. | ||
The structure of the proposal is identical to the `StewardFundingProposal` except that the author of the proposal is not required to be a PGF steward, and the voting conditions differ. | ||
The proposal will be such that it **is rejected** by default **unless** the following conditions are met: | ||
- $\frac{2}{3}$ of validating power must vote on the `FundingProposal` | ||
- More than half of the votes must be in favor of the `FundingProposal` | ||
|
||
The parameter of inflation income is set by governance and is included in genesis by default. | ||
That allocation is then allocated to each steward (more stewards = more total funding). | ||
Note that these are the same voting conditions as the `StewardProposal` |
11 changes: 11 additions & 0 deletions
11
packages/specs/pages/economics/public-goods-funding/incentives.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
# PGF stewards incentives | ||
|
||
Being a PGF steward is (should be) hard work. Stewards must invest their time in crafting proposals, being in touch with the opinions of the Namada community, and taking the risks associated with being voted out. | ||
In order to incentivise this effort, Namada allocates a set amount of NAM inflation that is directed towards the stewards. | ||
|
||
By default, this inflation is directed (directly) to each PGF steward account. The steward can then decide what to do with any collected funds. | ||
The Steward account can also unilaterally (within the rules of a multisig transaction) set up a stream of income to a separate set of accounts (e.g a set of personal accounts between the signers behind the steward account). | ||
The inflation is then credited directly to these set of accounts. | ||
|
||
The parameter of inflation income is set by governance and is included in genesis by default. | ||
That allocation is allocated to each steward (more stewards = more total funding). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters