# Frequently Asked Questions

# WARNING: This are slightly outdated, see the Glossary instead

# 1. How can maintainers onboard to the Git Consensus Protocol?

Kindly refer to the Maintainer Guide for a detailed onboarding process.

# 2. How does voting to reward contributors occur?

Once a new version is ready (a tag has been created), the stakeholders of a project decide on how to reward value to different commits.

Each maintainer will decide on a value to reward to a commit (value to commit hash mapping) and based on the weighted averages of these values(weight refers to % ownership of a maintainer), a final value is arrived at and newly minted tokens equivalent to that value are transferred to the contributor's address. Refer to the example in README.md for further clarity.

# 3. Where do the tokens rewarded to the contributors come from?

The tokens rewarded to contributors are newly minted(and not transferred from an existing owner's account) based on the final value decided to be rewarded to that contributor. The token contract invokes mint(address account, uint256 amount) function for this. For more implementation level details, refer to IToken.md

# 4. Is there a cap on the maximum number of tokens that can be minted for a particular project?

No, if a token could no longer be minted ever, it would be discouraging for any new contributors as they could no longer receive rewards. Minting as the only mechanism does have some concerns in regard to constantly increasing totalSupply() (aka. inflation). We may want to eventually offer an implementation that allows for Git Consensus to instead transfer tokens from a project treasury to committers. Both methods have their pros and cons.

# 5. What is the concept of Governor for a project?

Governor is the core contract that contains all the logic and primitives. You can find more details on governance here. For implementation level details, click here

# 6. Why is the token contract required to have a reference to the Governor?

Governor and token have a 1:1 mapping, meaning the token contract has reference to the governor address and vice versa. We need a token->governor reference to account for an attack vector:

Step 1: Badguy deploys a governor with it's governor.token() pointing to an already existing real token. This governor implementation will also disregard a normal proposal system (e.g. it executes functions immediately if Badguy calls governor.execute()).

Step 2: Badguy calls addCommit() with some commit messages that include Badguy's wallet address.

Step 3: Badguy calls governor.execute() to addRelease() with a tag message that includes to Badguy's governor address, and with a distribution that includes the commit hashes from Step 2.

# 7. What is the mechanism to determine the final reward for a particular contributor?

Based on the weighted averages of the values in the value to hash mapping distribution(weight referes to % ownership of a maintainer), a final value is arrived at and newly minted tokens equivalent to that value are transferred to the contributor's address. Refer to the example in README.md for further clarity.

# 8. How will a release of a project be approved?

The maintainers of a project onboarded to Git Consensus will decide to setup their governor to require a % majority for proposals to be executed. Once the configured quorum is met, addRelease() call will be able to be executed. The % threshold should be set cautiously as if it is set too high, vote participation per proposal is expected to decrease as the token becomes mores distributed. This could mean that this threshold is not frequently met.

# 9. Can maintainers onboarding to Git Consensus provide an initial distribution of tokens for themselves while onboarding?

Yes, maintainers can initialize a token distribution for themselves while onboarding. The process will be similar to what happens when a contributor is awarded tokens as rewards, The only difference being that instead of a commit hash->value mapping, an owner address->value mapping would be required.

# 10. Is there an upper limit to the reward each maintainer can vote for a contributor?

Yes, this is achieved through the maxMintablePerHash() function provided by the Token contract. For more implementation level details, refer to IToken.md

# 11. Is there a way for the maintainers to decide how much a commit is worth?

It is up to the maintainers to choose what value to vote for. This protocol makes use of the strong incentive mechanisms that the OSS community already relies on to behave well. For example, be incubated in the CNCF, your project needs to have sufficiently distributed contributors. And if you want downstream clients to actually use your project in production, they need to trust the authors. Not only will the project lose legitimacy in the OSS community, but these will also be reflected in the token price.

# 12. What benefit do the contributors derive from the tokens rewarded to them?

The more number of tokens a contributor has, the more will be the share of their ownership in the project. These owners may also choose to sell their tokens on the open market, giving them a source of income.

# 13. Why do contributors need to embed their wallet address into the commit message?

The GitConsensus contract maintains a commit hash->value mapping, and when addCommit() is called, this mapping is updated with the commit hash and whatever address was included in the message. During addRelease(), this address is retrieved, and the newly minted reward tokens will be transferred there.

# 14. How can contributers embed their wallet adresses in the commit message?

Kindly refer to CONTRIBUTOR.md for detailed steps.

# 15. What happens in case maintainers exhibit malicious behavior and keep rewarding only their own commits?

To remain painless and flexible, we make some assumptions about how this protocol will be used in practice. We assume token holders (specifically, majority token holders / maintainers) will behave in a way that supports their project’s legitimacy. Luckily, this currently occurs in the OSS community and has to for a project to be success. For downstream clients to trust using a project’s software, they already have to trust the authors. To be accepted in certain software coalitions the project generally needs have sufficiently distributed contributors.

Because an ERC20 token can be traded easily on the open market, there is also an additional metric that reflects the project legitimacy: a comparable TOKEN:USD or TOKEN_A:TOKEN_B price. If bad behavior is observed, it may cause fluctuations in this price.

# 16. What is the incentive for onboarding to Git Consensus?

The Git Consensus protocol enables distributed governance for a project and creates a powerful incentive mechanism where contributors both improve the project and become stakeholders in the project at the same time.

# 17. Can a maintainer transfer ownership of their tokens to another maintainer?

TBD

# 18. What happens if contributors don't embed their wallet address into the commit message?

TBD

# Still got questions?

Just create a new issue and you'll recieve an answer shortly!