search

git-consensus / contracts

Converts the informal ownership structure of an open-source git project to a formal DAO, with token distribution mechanisms for contributors.
GNU General Public License v3.0
13 stars 0 forks source link

💸 GitConsensus addRelease(): use transfer() instead of mint() for distributions #29

Open mattstam opened 2 years ago

mattstam commented 2 years ago

Instead of token.mint(), we could use the standard ERC20 token.transfer() if the GitConsensus contract is an approved to transfer that amount before-hand.

This would create alternative tokenomics models, such as having as designating a repository treasury. This type of model would could allow for a stable tokenSupply(), which is particularly desirable for those projects looking to maintain a stable trading price overtime.

DmitriyShepelev commented 2 years ago

Having the ability to mint and transfer would be a good idea. For example, if Alice thinks Bob made a particularly impactful commit to a repo R but doesn't want to increase the supply of the token for R (and thereby diluting the value of her tokens), she can transfer a subset of her tokens.

Having a dedicated repository treasury is an interesting idea. Project owners can have their repository treasury mint X tokens every Y blocks to ensure supply stability.

mattstam commented 2 years ago

For example, if Alice thinks Bob made a particularly impactful commit to a repo R but doesn't want to increase the supply of the token for R (and thereby diluting the value of her tokens), she can transfer a subset of her tokens.

Yep! Trying to play devil's advocate here, and this goes through my mind:

  1. If Alice wants to reward Bob, she can just transfer() her R tokens to Bob directly instead of having to go through GitConsensus and with correlated commit(s).
  2. @Bryce-Soghigian mentioned that status tracking as a particularly useful (e.g. if you made a contribution to a major project and got minted tokens, it is worth showing in a career-oriented page / resume). With minting this is simple to track because it's just tracking transfer(0x0, bobAddr). With transfer rewards, the first from address can be arbitrary so harder to filter.

Project owners can have their repository treasury mint X tokens every Y blocks to ensure supply stability.

What mechanisms currently exist for periodic calls like this? In my experience there needs to be something external (usually an EOA) to trigger any computation / state changes. I've seen periodic contract pollers a while ago, but am really behind on what the current patterns for this would be.

DmitriyShepelev commented 2 years ago

With transfer rewards, the first from address can be arbitrary so harder to filter.

Could we emit an event utilizing a minimal amount of gas to identify transfer rewards?

Project owners can have their repository treasury mint X tokens every Y blocks to ensure supply stability.

What mechanisms currently exist for periodic calls like this? In my experience there needs to be something external (usually an EOA) to trigger any computation / state changes. I've seen periodic contract pollers a while ago, but am really behind on what the current patterns for this would be.

Two ways come to mind:

  1. Use Chainlink Keepers (docs) to create a checkUpkeep function to see if a certain number of blocks have been mined.
  2. Use a modifier that runs after each function checking if a certain number of blocks have been mined, the block number is divisible by some sort of number, etc.

(2) would probably be more gas-efficient.