Factom Protocol Governance Background

In order for a blockchain to be truly decentralized, not only does the network infrastructure need to be sufficiently distributed, but governance and development, as well. If there is a central authority in any of those categories, the project is centralized. The Factom protocol is one of the very few blockchain projects that are decentralized across each category.

Factom Protocol Governance Background

In late 2014, Paul Snow and David Johnston discussed the possibility of creating a novel and innovative technology that would hash any kind of data and anchor this hash to the Bitcoin blockchain -- utilizing Bitcoin’s inherent security to its advantage. This technology would provide proof of existence, proof of authenticity, maintain the provenance of data, and would create an immutable audit trail. The founders chose the name “Factom” for this technology, which is based on the Latin word, factum, meaning “a statement of the facts of a case”, and became incorporated with headquarters in Austin, TX. For almost four years, this company, Factom, Inc. existed as the sole operator, developer, and marketer of what became known as the Factom Protocol.

On March 16th, 2018, Governance Doc 001 was presented to the Factom community, which would describe the framework and processes towards decentralizing the protocol. This crucial first document, which organized and implemented the forthcoming decentralization effort, was composed by and for all parties in the Factom Protocol ecosystem. This was a hallmark moment for the Factom Protocol -- Factom, Inc. was not the sole creator or contributor to this document. Instead, many members from the protocol community composed, omitted, amended, and presented sections of the document. This communal effort was followed by a communal vote, and on April 7th, 2018, the Governance document was overwhelmingly approved and ratified.

Fostering a transparent and clear process with which to deliberate and ultimately make Factom Protocol decisions, the concept of “Standing Parties” is outlined in Governance Doc 001. Standing Parties are described as parties having standing in the protocol to vote on protocol processes. However, beyond just voting, these Standing Parties have a voice in matters of governance, decision-making, and direction with the persistent intent of furthering the best interests of the Factom Protocol. To become a Standing Party, at least one “Category of Support” must be fulfilled, which refers to the idea that by contributing support to the Protocol, one can have a say in matters of the Protocol. Thus, as an agent intending to have a voice and vote in the ecosystem, the agent must contribute to the ecosystem in some way or another.

On May 2nd, 2018, shortly after Doc 001’s ratification, the Factom Protocol officially began its journey to decentralization with the rollout of Milestone 3 (M3). This new phase decentralized the protocol by allowing for the creation of Standing Parties by means of either applying to become a Protocol Guide or by campaigning to run Authority Servers which are nodes that validate transactions on the Factom blockchain. In time, other methods of achieving Standing will be made possible. An entity or individual must be included within one of the following Support Categories to receive Standing in the Protocol:

Current Categories of Support

Guide - Shortly after the ratification of Doc 001, the community held a vote to determine the five Guides who would lead the initial movement towards governed decentralization. The Guides were selected based on their community participation, work ethic, good reputation, and knowledge of the Protocol. Guides do not have any executive power, but they do facilitate processes in the ecosystem, compose and amend governance documents with community approval, and push forth relevant discussions and votes.

Authority Set - After the election of the Guides, campaigns to become an Authority Node Operator (ANO) began. ANO applicants are typically comprised of individuals, companies, entrepreneurs, and Protocol enthusiasts. Guides had to evaluate the first ANO campaign documents and applications, and elected the first ANO’s because there were no other Standing Parties that existed yet. ANO’s are tasked with running reliable nodes, ensuring personnel are dedicated to node maintenance, pledging “efficiency” towards Protocol development, and should further the Protocol in some demonstrable and valuable way.

Future Categories of Support

Efficiency - In the Factom Protocol, a given ANO’s “efficiency” is described as the portion of an ANO’s compensation that is consciously specified as unclaimed by the ANO so that these specified funds can be diverted to the Grant pool to fund Protocol-related projects. Although not implemented as a Category of Support yet, calculating the value of support for efficiency, “uses a sliding scale with those levels of efficiency (the difference of the draw and the maximum token issue) in the last 30 days weighted at 100%. With each month, the weight of efficiency is reduced by 20%, such that efficiency greater than six months back provides no support.” [Doc 001, 6.2.5.2].

Grant Success - Grants are Protocol-based projects that seek funding from the Grant pool. As mentioned earlier, the Grant pool is funded by the efficiency of ANO’s. Although not implemented yet, successful handling of prior Grants will be rewarded by 24 months of Support, and Grant success is defined by milestones achieved combined with the grading of the Grant’s success as specified by the Standing Parties.

Proof of Use - Actual usage of the Protocol is another potential (future) Category of Support. When a user buys Entry Credits, which allows the user to make entries into the Factom Protocol, the user achieves Standing. At point of purchase, the entry credits are weighted (in terms of voting power) at 100%. Each month thereafter, the weight of this purchase reduces by 20%. Thus, entry credits purchased over six months ago would no longer hold any weight.

Proof of Stake - At some point in the future, holders of Factoids (FCT’s) that stake some number of FCT’s to have a say in governance (via voting power) will also be able to achieve Standing. There are two kinds of staking: retrospective staking and prospective staking. In retrospective staking, “tokens allocated to a proof of stake address assigned to a standing party will accrue additional voting weight equal to 5% of the original token count each month they are left in the proof of stake address until 24 months. After 24 months, no further weighting will accrue. (Note: Additional tokens will not accrue, just additional voting power.)” [Doc 001, 6.2.1.2.2]. In prospective staking, a token “locking” mechanism will occur, wherein a FCT holder stakes some number of FCT’s, and those tokens become locked and untouchable for a predetermined time period.

Governance Doc 001 also details the process for amending governance documents, describes the process of vote delegation (not yet implemented), specifies the process to remove ANO’s from the Authority Set, and elaborates on a variety of salient considerations within the Protocol. The Factom Protocol has transitioned from an ecosystem led by Factom, Inc., the founders and original developers of the protocol, to what is now a developing collaborative, decentralized, and governed ecosystem.

Showcasing Our Decentralized Governance

As there is no central authority within the Factom Protocol, but a need for many specific tasks to be planned and executed, a series of committees and working groups have been formed. The current committees and working groups can be seen here.

Efficient Governance needs sounds processes, but if you have a single person or entity dictating those processes, then you're centralized. Here's the Factom Protocol’s solution to creating governance processes:

1. The community will collectively draft a document in our Governance Discussion forum via a "Major Timed Discussion". "Major Timed Discussions" are held via a software modification we created that specifies 8 days for the discussion. A bot helps moderate the discussion, and specific parties are invited who can take part. The software modification also lets us make motions to extend the discussion or end it early, and someone can second that motion and the motion goes up for a vote. You can see an example of that process here.

2. After that Major Discussion, the drafted document goes to our Legal Working Group for review and suggestions.

3. After legal review, the drafted document then goes to our Document Ratification area located here. This once again uses a proprietary software modification where over 8 days, the document goes through further revisions until the software automatically holds a vote at the end of that period. If the vote is in favor of ratifying that document, it becomes part of our governance. If not, then it does not, but the document can start the process over if someone so desires.

As further Standing Parties are onboarded, they will be allowed to take part in this process.