53 lines
3.4 KiB
Markdown
53 lines
3.4 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.
|
|
|
|
---
|