The concept of Contribution Contracts belongs to our Contributions Governance System. The purpose of the system is to allow the community to propose projects and vote for them.
By definition a Contribution Contract or CC is an agreement between a team or individual and the Fermat project represented by its community. Fermat needs to develop into a global infrastructure. It was bootstrapped by its founders and early contributors until the point where the project can have a new degree of autonomy. Fermat is running an economic model through its blockchain system, where 21M IoP tokens are going to be issued over the course of around 80 years. These are the main resources of the project to finance its expansion.
We already know that half of those IoPs are going to be mined and the other half are going to be distributed to the community through Contribution Contracts. This means that there is a huge opportunity to become a stakeholder of Fermat by being compensated for a project, while adding value to the Fermat ecosystem .
The project is currently transitioning from the bootstrapping phase into the autonomous phase. In these very early days of the autonomous phase, Fermat mostly trusts people who are invested in its tokens and assumes that the more invested they are, the more their personal interests are in line with the vision of the project. For proposing CCs people thus need to be invested and hold at least 1,000 IoPs which act as a deposit through the whole lifecycle of the CC. 1,000 is an initial number balancing the need to be invested while not excluding enthusiasts with good ideas. The deposit amount of 1,000 is set as the initial value and will decrease over time , since the IoP token price will raise with demand and 1,000 IoPs could be of substantial value one day. We as a community should research how this number should evolve after we will have collected feedback over the next months and derive a formula that can survive over time. Besides that proof of stake, a fee of 1 IoP is required for each CC submitted to the governance system. This should prevent spamming the system.
Contribution Contracts need to be voted by the community in order to be accepted by the governance system. The only possible votes are YES or NO. It is expected that the community members debate the CC and finally issue their votes. Currently the most invested community members are the most trusted ones for proposing a CC. Later the Contribution Governance System will evolve to include reputation of the participants and will consider their voting history and outcomes of projects. But we are not there yet, so as of today, to vote it is required to be an IoP token holder.
As some early contributors including myself are holding substantial amounts of IoP tokens, we need a way to protect minor investors against self-approved CCs. Bearing this in mind, several measures have been implemented:
- NO votes are cheaper than YES votes: To issue 100 NO votes you need a deposit of 20 IoPs, while to issue 100 YES votes you need to deposit 100 IoPs.
- Vetting Period: After the voting period of a CC, there is a fixed-time vetting period where only NO votes can be issued.
- Voting Fees: Each vote cast carries a fee of 1% of the tokens used to vote. This is a strong disincentive to use excessive voting power for subjects that don’t really require them or as a way to avoid an open discussion or democratic participation. These fees are turned into mining fees and collected by miners.
Approved CCs are paid directly by the blockchain during the CC execution period. In other words, every time a new block is mined, 1 token issued by the blockchain is allocated to one of the miners, and 0 to 1 IoP is given to the beneficiaries of currently executing CCs.
Deposits serve as a proof of stake of the community members, entitling them to participate in this process. Deposits are checked at every block during the whole life cycle of CCs. If the system detects that deposits have been withdrawn (IoP spent), then it will consider either the CC canceled (if it was a deposit of a contract) or the vote canceled (if it was a deposit of a vote).
A canceled contribution contract will halt any further payments to their beneficiaries and the system considers this a final state. A canceled vote might or might not impact the outcome of payments. Canceled YES votes might result in less YES than NO votes for that contract and in this situation the CC is canceled and payments halted.
Voting is pseudonymous. This means that a single person could vote the same CC more than once if he creates the right setup running the voting app with different accounts. In these early days we can deal with that since the size of the community is not too big. It might also continue like this later, depending on feedback collected during the first months. It is important to note that we are deep inside uncharted territory with this type of governance.
CC Life Cycle
CCs go through these four phases:
- Draft: Once you create a CC,a new post on the community forum is posted. The CC still has not entered the system yet. At this stage the CC is considered a draft. You will notice that the Contribution App requires the deposit even to create a draft. This prevents spam by individuals that don’t really have the means to propose a contract. During this phase the project is debated by the community using the forum. The submitter can defend this position and answer questions, present more material, detail milestones and deliverables and receive feedback. After he feels comfortable that his project is going to be accepted he can submit the CC to the governance system thereby entering the next phase. If the feedback he is receiving is mostly negative and he has reason to believe that his proposal might be declined, he should better forget about this contract and cancel it. He might cancel it in order to lower the amount of IoP tokens requested in case that was a factor for disapproval of his project. All contracts and their voting history are recorded on the immutable database called blockchain and this data will later become the reputation of the different entities participating: contract owners and voters. This implies that it is very important to keep a good track record or else this will damage one’s reputation.
- Voting Period: This period starts when the contract is submitted to the governance system, a.k.a the blockchain. The contract owner defines the duration of the voting period, although there is a minimum of around a week. YES or NO votes can be cast during this period. A necessary condition for a CC to be considered active for the next phase is that the sum of YES votes must be greater than the sum of NO votes and there must be at least 5 different blockchain transactions with YES votes, each one with a minimum of 100 votes. If all these conditions are met by the end of the voting period, the CC advances to the next phase.
- Vetting Period: During this phase only NO votes can be cast. NO votes also have a minimum of 100 per blockchain transaction. If during this period NO votes are equal or greater than YES votes, the CC is cancelled. If not, it enters the next phase. The Vetting Period is a fixed amount of time of around one week.
- Execution Period: This is the phase where CCs are paid by the blockchain. In the CC its owner must define how many IoPs he demands to be paid for every mined block. The amount can not exceed 0.1 IoPs, since there is only 1 IoP per block to pay all CCs, so a single contract shouldn’t take it all. This initial arbitrary value of 0.1 IoP means that there is room for 10 CCs to be paid in parallel if all of them demand the maximum payout. As the token market price increases over time, this number should be adjusted and lowered below 0.1, so that the system can pay for more CCs in parallel. If for any reason there is no room for more approved CCs contracts and the system is already spending the 1 IoP assigned for this, then CCs are placed on an execution queue and they will wait for room to enter into payment mode. All this happens automatically and there is no way someone could prioritize one contract over others. Approved CCs are paid on a first arrived first served bases, that means that it is important to go through the process in a timely manner to avoid payment delays.
If a CCs is executing and being paid and the beneficiary team is not delivering their promises, then people that voted YES for that project can remove their votes at anytime just by withdrawing the deposit. This is the last resource mechanism that allows the ones that participated in the discussion and further voting period to cancel a bad project. YES votes can not be equal or less to NO votes. Also YES votes can not drop below 50% of the original YES votes the CC was approved with. Any of these two conditions will cancel CC and payments are halted.
There are some more minor details and for sure a lot of room for improvement. It is up to the whole community to improve the system and find possible vulnerabilities. We should all consider this a groundbreaking social / technical endeavor and see how we make it work.
Thanks to Amadeo Charlé for the editing.
If you are interested in learning more about Fermat technologies, this list might help you:
- “Fermat, the Internet of People and the Person to Person Economy.”
The Internet of People architecture dissected.
- “Introducing the Graphchain.”
The cryptographically secured data structure we use to store profiles and their relationships.
- “Introducing Redtooth”
Like Bluetooth with global range.
- “The Profile Server.”
The cornerstone software of the Internet of people.
- “The Location Based Network.”
The geo-located network that help other services to be geo-localized.
A bit about me: I am a systems architect who started his career designing and building banking systems. Later I turned into an entrepreneur. Three years ago I learned about bitcoin and decided I would use the underlying technology to fix the biggest problem we have as humans: “unlimited concentration of power”.