search

OpenZeppelin / openzeppelin-labs

A space for the community to interact and exchange ideas on the OpenZeppelin platform. Do not use in production!
https://openzeppelin.com/
MIT License
375 stars 116 forks source link

Kernel Governance: TCR research #36

Open maraoz opened 6 years ago

maraoz commented 6 years ago

Read about Token Curated Registries and determine how much we can reuse/adapt for zOS kernel governance

maraoz commented 6 years ago

@spalladino assigned to you based on your previous work on this. Care to share your document and conclusions here?

spalladino commented 6 years ago

Here it goes. I'll update with conclusions as soon as I draw any from this research!

Token curation resources

Curation market

A token specific to a community is issued with continuous minting, with a price that increases as supply increases. The money raised from the sell is kept in a communal pool, and at any time people can exit by selling the tokens back. The selling price will depend on the current supply, so early adopters may turn in a profit.

The token can then be used to signal approval towards specific information or decisions. Holders stake their tokens towards a particular piece of information, granting it a percentage of approval within the market. They may also choose to delegate their backing to a curator.

A curation market is a smart contract on Ethereum that is deployed for a specific shared goal or topic that allows the minting of tokens set by a hard-coded algorithm. The cost (in ETH) to mint a token increases as the supply increases (as more tokens are minted). The cost decreases as the supply decreases (tokens are withdrawn (“burned”) from supply).

The minted tokens are bonded to specific curators chosen by the token holders per sub-topic. Using their proportional standing in the curation community (per topic), these curators then back certain information (equivalent to an “upvote”). They can also revoke their backing.

Minting could additionally issue extra tokens to a beneficiary, such as foundation or implementor. If the token belongs to a project, and is used for prioritising development, a fraction could be issued to the development team. Also, an initial token launch could be used to bootstrap the token, which then continues with a continuous minting model.

The core, functional components of curation markets involve:

  • A token that can be minted at any time (continuous) according to a price set by the smart contract.
  • This price gets more expensive as more tokens are in circulation.
  • The amount paid for the token is kept in a communal deposit.
  • At any point in time, a token can be withdrawn (“burned”) from the active supply, and a proportional part of the communal deposit can be taken with.
  • The tokens are used to bond it to curators per sub-topic, who then curate information with their proportional backing.

Curation markets may split into sub-markets, where the token for the sub-market can be purchased using the token for the parent market. This does not require permission from the parent market, and may happen naturally as a market grows.

Curved bonding

Use a more general token (such as ETH) to buy a project token (such as ZEP). The price of ZEP increases as the supply increases (curve could be linear, logarithmic, or any other kind). ETH used for purchases is kept in a communal pool. Buy and sell price may have a gap, to force buyers to stay for a time before selling.

Curved bonding is ideal to be used as pricing mechanism in curation markets.

The basic premise of curved bonding is as follows:

  • With a specific token (eg ETH), you can buy a new token (eg #projectToken) through a smart contract. The ETH is kept as deposit within the smart contract. It’s not disbursed to any particular person or team.
  • The buy price is determined by the current supply of the new token (#projectToken). The buy price is hardcoded according to some algorithmic curve.
  • At any point in time, someone can sell back their #projectToken into the communal pool and get out an appropriate reward that is set by a sell curve.

This setup means that #projectTokens will form and dissolve as necessary. If everyone leaves, all ETH will be refunded and all #projectTokens will cease to exist. If you buy in early, you will get more tokens for the same price. If you buy in later, you will get less tokens for the same price. If you sell back into the pool, you will get less ETH per token vs selling back into the pool when the outstanding supply is higher.

Bonded curve can be used for pricing goods. Access to a good may be set as a fixed price in projectTokens, and the price of projectToken determined by a bonded curve. Users can buy projectTokens, and either keep them (guessing that demand will increase, increasing the price), or redeem them instantly for access to the good. The provider of the good can also choose to sell the tokens immediately back into the communal pool (and get ETH back), or keep them (guessing that the demand and price will increase) to sell later.

Curated registries

Token-curated registries are decentrally-curated lists with intrinsic economic incentives for token holders to curate the list’s contents judiciously.

A token-curated registry is a list of curated entries. It requires a specific token for the registry, and involves three roles:

Voting can follow any scheme, as long as it relies on the number of tokens of the holder, and a commit-reveal mechanism is used.

Continuous token curated registries mix registries with bonded curves. These are curation registries, with a continuous token emission model similar to curation markets. In these registries, the token is not minted initially in a token generation event, but anyone can buy or sell a token at any moment. The price of the token is proportional to its supply, so a higher interest in the registry should cause more people to buy the token, and drive its price up. This further incentivises the token holders to make a good job curating the registry.

The main difference between token curated registries and markets is that the former are binary (ie a participant is or is not part of the registry), while markets allow for signalling a continuous level of approval.

References

spalladino commented 6 years ago

Following is a potential idea for kernel mechanics derived from token curated markets. I'm writing it here for future development, since we'll probably be tackling it after the MVP.

Token curated market per kernel version

Each new kernel version is represented by a token, with an associated token curated market, with different buy and sell curves. A token for a specific kernel version A, let's say TKA for short, can be purchased in the curation market with ZEP tokens. Whenever TKA are purchased, the developer who proposed version A gets a small percentage of the purchase (in TKA) as a reward. This generates a payout to the developers behind a version whenever ZEP holders vouch for a particular version.

Usage of token curated markets also incentivise early discovery of good new kernel versions, as token holders will be interested in buying in early in promising kernel versions.

Proposal of new versions

To prevent spamming, a developer who wants to propose a new kernel version B is required to buy in an initial batch of TKB. The difference in buy/sell curves could be implemented such that, if the developers attempt an immediate sell of TKB for ZEP, they actually lose a significant amount of tokens in the process.

Development bounties

Besides signalling approval for version A, TKA can have other uses, such as development bounties. TKA holders may be allowed to stake their tokens as a means to request a particular development on top of version A. Developers can then propose an implementation of the requested feature in a kernel version A2. The TKA holders who staked their tokens in that feature can be given the option to switch their tokens from TKA to TKA2 at a preferred rate (or during an initial restricted setup stage).

This way, instead of directly paying out to the developers for implementing that function, development bounties are paid out via the fees awarded to the developer who proposed a version when users buy that version token. And users are incentivised to purchase TKA in order to stake them towards a feature, and get an edge in investing early in TKA2, if they believe the feature is worthwhile.

Market trees

A further enhancement of the token curation markets is to mimic the kernel version trees as tree-like curation markets. Let's say that kernel versions TKA1 and TKA2 are proposed, both of which extend from TKA. Then, the curation markets for TKA1 and TKA2 can require TKA instead of ZEP for buying in. This ensures that the developers of version A get a fee whenever a user wants to buy either TKA1 or TKA2, since they are forced to buy TKA in the process. This way, the dependencies tree is mirrored in the curation markets tree.

Inflationary tokens vs purchase fees

Instead of developers collecting a fee from every purchase of TK, an alternative for rewarding them could be making all TKs inflationary. Every certain time, for version A, the system would mint a number of TKAs for its developer, proportional to the total supply of TKAs. This way, value is moved over time to the developer who proposed a version, as long as users remain interested in that version.

TCRs for whitelisting versions

To prevent malicious teams of developers from proposing code stolen from other development teams, or not properly indicating that their version TKA1 extends version TKA, or any other malicious behaviour, a TCR could be set up for approving new kernel versions.

All proposed kernel versions could require get approval from a TCR, managed by ZEP token holders, in order for their kernel to be accepted as a candidate, and its own token curated market set up within zeppelin_os. This would act as an initial barrier to prevent foul play in the system.

maraoz commented 6 years ago

Awesome research and proposal. Moving to https://github.com/zeppelinos/labs/milestone/2 as it's out of scope for https://github.com/zeppelinos/labs/milestone/1

spalladino commented 6 years ago

A new post from Simon proposes a combination of Bonding Curves and TCRs. Every time someone buys in, a set of beneficiaries receive a fraction of the purchased tokens as a reward. Such set is defined by a TCR.

This would allow another approach for rewarding Kernel developers. Instead of having a token per each kernel version, a single token can be used (or a single one per kernel distribution, or other grouping), and the developers that receive the rewards chosen via a TCR. This requires a bit more coordination though, and one of the previous approaches may actually be more efficient.

spalladino commented 6 years ago

@fzeoli mentioned offline that a potential issue with using token curation markets per-kernel version, and it is that it heavily punishes honest players who vouch for an apparently fine version, but a bug is discovered in it later, causing a mass-exit from that token and crashing its value. This makes the risk for vouching too high.

This could be circumvented by defining Market Trees as described above. If a "good" version is found to have a critical bug, it is expected that a new one (or more than one) would immediately spawn from it fixing the issue, and vouching would move to it. Now, if tokens for the new version can only be acquired in exchange for the tokens of the parent version, the price of the parent version would not drop. In other words, the value of the token of a version only drops if stake is moved to another branch of the tree, but not if it moves to a child (or descendant).

The main issue with market trees is that, for long development lines (ie a large number of versions across time), it could be an issue to reach the "target" market, requiring exchanges in many different intermediate markets. A possibility would be to add "shortcuts" to certain markets (such as major releases) so they can be purchased directly with ZepTokens or ETH.