Fermat aims to develop a distributed governance model. The most advanced of its kind today is the one implemented by the anonymous cryptocurrency DASH. Fermat’s governance model takes DASH as a starting idea with several new additions and changes, customized to meet Fermat’s goals of decentralization.

We identified three different actors in our governance system:
Contributors: Can be any individual or entity in general willing to provide a service to the project as a contractor. This service could be related to software development but not restricted to it. Marketing, business development or any other valuable activity may be carried out by contributors.
Voters: Any token holder has the right to vote using their tokens as voting power. We believe that decisions regarding a project like Fermat should not be in the hands of only geeks, but should be decided by the community as a whole.
Blockchain: The blockchain is the entity recording immutable data and minting new tokens. We need both of these properties for our governance system.

From the software perspective 5 components are needed for such a governance system. These components are:
- Mobile App for Contributors: This is a reference app that allows contributors to create and manage Contribution Contracts. Anyone may propose a project, which is then accepted or declined by the community. These contribution contracts detail the services contributors expect to provide if the terms and conditions are accepted by the community.
- Mobile App for Voters: This is a reference app that allows community members to vote for the Contribution Contracts they support.
- Web Forum for Discussion: At a public web forum Contribution Contracts details are discussed both by contributors and community members, which assists everyone’s formation of opinion.
- IoP Token Server: The token servers and its blockchain are used as an immutable database to record both Contribution Contracts and Votes casted by community members.
- IoP Minting Server: Projects which are supported by the community are funded by the blockchain, which automatically allocates a portion of all newly minted tokens towards the contributors responsible for the execution of these projects.

So the process is very straight forward:
- Contributor Creates a Contribution Contract: The contributor’s app allows end users to create a new Contribution Contract. The contract is recorded on the blockchain and a new thread is created on the web forum by the app, starting the discussion about the proposed project.
- Contract is Discussed at the Forum: The voter’s app detects the new Contribution Contract on the blockchain and alerts voters accordingly. Voters can read the forum discussion with their app and interact with the rest of the community, evaluating the proposed contact.
- Community Votes YES or NO: Using the same app, voters can cast their vote for YES or NO to individual CCs. They can also abstain from voting if they don’t want to. These votes are recorded on the blockchain as IoP token transactions with special characteristics. No information of who casted each vote is required.
- Minting Server pays Beneficiaries: Some part of the Contribution Contract information recorded at the blockchain contains a list of beneficiaries to be paid (IoP address and amount). The Minting Server issues new tokens and pays these beneficiaries when all conditions are met.

Once the basic scheme is laid out, we need to solve a long list of problems we might face. The first one is how to prevent Contribution Contracts being used as spam, and dispersing the attention of the community into too many contracts to review. The solutions to this problem are straightforward:
- Contribution Contract Collateral [CCC]: We just need to require a Contribution Contract Collateral to be deposited at the contributor’s account during the review process, the voting process and the execution of the contract itself. Removing this collateral immediately invalidates the contract and all software components will just ignore it. Holding the collateral is automatically done by the contributor’s app.
- Contribution Contract Minimum Mining Fee [CCMMF]: A minimum mining fee for the contract transaction at the blockchain is required to prevent spam even from invested contributors.
Both requirements, the CCC and the CCMMF have an initial default value that is later re-calculated by a process similar to the one that recalculates the network difficulty in PoW mining. The initial value for CCC is established at 1,000 IoPs, while the initial value for CCMMF is set to 1 IoP.

Even with the requisite of a collateral the system might grow to manage multitudes of valid Contribution Contracts at the same time.
- Contribution Contract Categories: The first criteria to manage this at the voter’s app is to allow the contributor to categorize the contracts. In this way voters can browse independent categories and help them filter out the contracts on domains they are not experts in.
- Mining Fee as Sort Order: The second criteria is establishing a sort order by a mining fee paid by the contributor when recording the CC at the blockchain. This allows contributors to invest in their contract as much as they wish. The more they invest the higher their contract will appear in the list of proposals at voter’s app.

If voting would be for free, then a lot of non expert people would be casting their votes regardless of the consequences of their ignorance. To avoid that we need to impose a Voting Fee [VF] implemented as a blockchain mining fee. This Voting Fee is a % of the tokens used to vote. The initial value is 1% and later this value is re-calculated by the same process that recalculates the CCC and CCMMF to adjust it to the system real life usage.

As voting is pseudonymous we expect contributors to vote for themselves, saving money to other community members. This carries a significant problem to be solved: how do we prevent contributors to always approve their contracts in the situation where these contributors are at the same time large token holders.
We found a solution in the concept of Voting Power. Voters don’t vote with tokens, but with Voting Power. 
Consider the following rules:
- Yes Voting Power: Each token can be converted to 1 YES vote.
- No Voting Power: Each token can be converted to 5 NO votes.
This means that for example, if a CC is voted YES with 100 IoP tokens, it is considered to have 100 YES votes. Anyone holding 20 IoPs can vote NO and cast 100 NO votes preventing the contract to be executed.
When the system starts, the biggest token holders might not be stopped by this measure, since the token concentration is high among funders and early contributors. This situation just maps the reality of the project before the voting system is in place, since funders decide on the fate of the project at this early stage anyways. But as time goes by, with a highly decentralized mining scheme as the one envisioned by Fermat, tokens are spread among a wide community. At a certain point in time there will be no single token holder having enough leverage to prevent their contracts to be vetoed by the rest of the community using No Voting Power.

Reviewing a Contribution Contract for approval takes time and effort. Reviewing the work done could be even more time consuming. If contributors are to be paid at a pre-defined date, there might not be enough time to verify that they fulfilled their part of the contract. To deal with this, we have come up with these countermeasures:
- Deliverable List: This is a simple list of URLs to web resources like documents, presentations, videos, websites or whatever is expected to be a deliverable of the contract. This list is very useful for community members to verify the work is being done and in a timely manner (the list also includes the deadline for each deliverable).
- Anytime YES vote Removal: To complement the deliverable list, we need to allow any YES vote to withdraw their support of the contract at anytime. This can mean that the contribution contract might never be executed or that its execution can be halted at anytime and payments stopped.
- Anytime NO Voting Possible: This is a tool for any community member to vote against a contract that is not delivering what it promised.
For these mechanism to really work, we need to separate ourselves from the idea that the contract is going to be paid on a specific date and think about the contract being paid during a period of time, expressed on blockchain block terms with a starting block, an ending block and an amount to be paid at each block of the range. This enables us to halt the execution of the contract once the community detects that the promised deliverables are not there at the promised time, but also in many cases the community can track the progress of these deliverables in real time (think of a web site being built, or an analysis document being produced, or a software implemented) and halt the execution of the whole contract if they perceive the contributor is not doing a good job and will not be able to fulfill his promises.

The issuing of IoP tokens for paying contribution contracts must be capped for several reasons:
- Preventing Abuses: Since both contributors and voters are pseudonyms, we need to avoid attack vectors where a contributor votes for his own proposal and very quickly the blockchain issues any amount of tokens. Since the tokens to be issued are capped at 1 token per block for all approved contribution contracts, that prevents this situation to happen. A secondary measure is that CC need a certain amount of blocks to mature and be considered valid. In this way it is not possible to immediately execute a CC that was just created. Time is needed to allow community review and voting.
- Having a Predictable Token Inflation: The economic system of IoP tokens works better when the supply of new tokens is predictable. In our case we start with a 1 IoP maximum that can be issued at every block for Contribution Contract purposes. So the issuance is in the range of [0..1] IoPs plus 1 IoP for miners. (All this is early stage where no halving has yet occurred). This might not be enough if the token price is too low, or might be too much if the price is too high. We will need real life data to fine tune this or do further research with appropriate simulations.

This was an overview of the Fermat Distributed Governance system that allows the project’s community to decide about the direction of the project and who to hire for the human work necessary. There are many more lower level problems to be solved not described here. A more detailed and technical information on this subject can be found at the Contribution Contracts section of the IoP Software Specification Document. The project’s roadmap expects this governance system to be released by December 2016. We expect this system to work well and scale during an early phase of the project. With experience and data collected from real life usage, it will be possible to identify further problems to be solved and addressed with appropriate counter-measures. We do like the concepts of voting delegation and liquid democracy but only as a solution of specific problems that today, because of such an early stage, we don’t have.
Thanks to Amadeo Charlé for the editing.