59 lines
3.9 KiB
Markdown
59 lines
3.9 KiB
Markdown
Reputation Tokens
|
||
|
||
Minting
|
||
|
||
Suppose it's possible to mint a reputation token.
|
||
Say we have a contract that keeps track of all the reputation tokens.
|
||
Suppose the reputation contract implements ERC720 (NFT).
|
||
Assume a validation pool always corresponds to a post.
|
||
A single token could be minted for each validation pool.
|
||
That token could be subdivided so that each winning voter gets some.
|
||
Perhaps voters get tokens that are specifically identifiable as governance reputation tokens.
|
||
Then the main token can be awarded to the post author.
|
||
Each token should carry a specific value.
|
||
The forum will update the value of the token for the post author as well as posts affected by its chain of references.
|
||
|
||
Then, when participants wish to stake reputation (for voting or for availability),
|
||
they must specify the amount and the token address which carries that reputation.
|
||
The token should probably then lock that reputation, preventing it from being staked concurrently for another purpose.
|
||
|
||
Perhaps our interface can allow staking reputation from multiple tokens at the same time.
|
||
And/or we can provide a mechanism for consolidating tokens.
|
||
|
||
Or maybe, if reputation is staked via a given token, then the reputation awards should go to that same token.
|
||
In that case, when should new tokens be minted?
|
||
|
||
Maybe a token should be minted for each validation pool, but not subdivided.
|
||
Voter rewards can just add value to the existing tokens from which reputation was staked.
|
||
|
||
Maybe a new token should only be minted if the author did not provide a token from which to stake reputation on their own post.
|
||
This supports the case of a new author earning their first reputation.
|
||
In that case the author may need to pay a fee to buy in to the DAO.
|
||
Or perhaps they can be sponsored by one or more existing reputation token holders.
|
||
Existing reputation holders could grant some reputation to a new member.
|
||
Perhaps there could be a contract that allows sponsoring a new member, such that whatever fee is given,
|
||
that fee will automatically be repaid from the new member's earnings, before the new member starts receiving their share of earnings.
|
||
This could be a multi-party action, or could just be a generic operation that can be performed multiple times.
|
||
|
||
However, this effectively allows buying reputation, which goes against the core concept of reputation as evidence of performance.
|
||
|
||
It could make more sense for new members to submit some sort of petition, i.e. to make a post.
|
||
|
||
Maybe rather than submitting fees, existing members can grant some of their own reputation to a new member, and receive some sort of compensation if the new member does well.
|
||
|
||
So far the only workable model seems to be the idea that a new member must submit a post along with a fee, in order to be considered, and if the post is approved, they gain their first reputation.
|
||
The amount of this fee can be up to the applicant, and/or can be regulated by soft protocols within the DAO.
|
||
|
||
If this is the only scenario in which new rep tokens are minted, and from then on their value is updated as a result of each validation pool,
|
||
then we probably want each token to store information about the history of its value.
|
||
At a minimum this can be a list where each item includes the identifier of the corresponding validation pool, and the resulting increment/decrement of token value.
|
||
Each validation pool can then keep a record of the reputation staked by each voter, and the identifier of the corresponding post.
|
||
|
||
---
|
||
|
||
So: If some incoming reputation can’t be propagated due to a constraint like this, the question is what should happen with that unspent power. I think right now, I have it so when that limit is reached on leaching from PostA, the extra reputation accrues evenly (because of +0.5 citation) equally to PostX and PostZ.
|
||
|
||
Intuitively, we might want less value accruing to PostX, as it seems intended as a small utility post to transfer power.
|
||
|
||
However, we can combine these mechanisms. PostX
|