Participating Projects

The purposes of Tezos are to provide a robust and secure decentralized platform for assets and applications with a native currency, tez. Tezos has a native upgradability mechanism and a modular architecture, enabling regular upgrades while remaining a credibly neutral, decentralized network. The core Tezos protocol is written in OCaml and uses a domain-specific language called Michelson which facilitates formal verification, a technique common in aerospace and financial contexts, to ensure code correctness.

As a secure, upgradable decentralized platform, Tezos provides a basis for financial applications, user-controlled organizations, and new kinds of peer-to-peer markets. One potential proxy metric for success is the total value of on-chain assets and activity enabled by its capabilities.

Tezos itself provides a native mechanism for coordinating its network validators or “bakers”, to govern protocol upgrades on-chain in a decentralized way. Bakers can submit proposals to change constants, the protocol, or even the governance process itself. Off-chain, Tezos is also supported by a number of organizations around the world, including TQTezos, Nomadic Labs, Tezos Commons, and the Tezos Foundation. The Tezos Foundation’s role is primarily one of an endowment, funding projects and has committees governing key funding decisions. 

There is significant interest in the Tezos community to experiment with new approaches for funding development and improvements to Tezos. One such DAO framework, BaseDAO, is currently in development by TQTezos to enable such experiments.

Governance in Tezos is mediated by “bakers”, the validators of Tezos. Bakers obtain the right to participate in the process by acquiring a ‘roll’ of tokens (currently 8,000 ꜩ). They could have assets delegated to them by others as well. These validators stake (or lock) this roll in order to begin processing and endorsing transactions on the network, and in doing so, can be randomly selected to ‘bake’ future blocks. They are then granted a block or endorsement reward for doing so. 

As for the upgrade process, these validators are required to vote on proposals and are the only participants directly involved with the process. Indirectly, discourse occurs through a number of social channels and by a larger number of individuals and organizations that can affect validator decision making. One example of a proposal that can modify this process would be to change the roll size, the number of locked assets required to become a validator. This most notably happened during Tezos’ Athens upgrade which lowered the roll size from 10,000 to 8,000.

The protocol upgrade process is on-chain and transparent and open to any participant directly who can participate as a baker.. Because Tezos amendments are ultimately technical upgrades, community developers have a big influence on feature prioritization as well. 

The project seeks to incentivize the following behaviors: 

• Successful validation of transactions with limited to no consensus failures

This aspect is incentivized primarily by the costs of network failure. If the Tezos blockchain doesn’t run efficiently, then it has failed as a resilient and decentralized platform sufficient for applications. 

• A wide validator set in order to increase network resilience and diversity 

This aspect is incentivized first and foremost by financial benefits due to validators receiving a portion of block rewards. Second to this is network diversity and security through a larger body of stakeholders voting on protocol upgrades. This incentive also leads to keeping the upgrade process as a calculated and coordinated effort. 

So far it has been going well. The network has undergone multiple upgrades, and currently has over 420 active validators around the world keeping it running. The governance mechanisms to date have worked and will hopefully continue working as Tezos continues to upgrade. Tezos’ governance process has handled several difficult moments to date, including an important bug discovered mid-cycle during 2019’s Babylon proposal, requiring a hotfix.

Currently, Tezos operates with a number of grant-based and service contract-based initiatives that are doled out by real-world entities. Eventually, a goal is for Tezos to use the network’s native invoicing mechanism (described in the White and Position Papers) to fund core development and to use on-chain DAOs to fund ecosystem public goods. The native invoicing system is a mechanism by which developers can include an invoice address to their proposals which is funded by network inflation. This has only been used with small amounts of tez to date and has not been used as a major funding source.

An illegitimate decision in the context of Tezos would objectively be one that breaks consensus, forks the network, or subjectively one that is perceived by users and the community in the best interest of the network.

Injecting a proposal into Tezos can be accomplished by any baker. The baker must have the latest protocol branch with a running node and the client installed. Then, the baker through their node can inject the proposal through a few commands and a hash.

Decisions on proposals are made by bakers through multiple voting periods. If a proposal period has active proposals, the proposal with the most supporters is selected to move onto the testing period. If there is a supermajority in favor of the proposal in the second round of voting, the proposal moves onto a testing period. A testing period begins with a 48-hour test and a forked chain to test a correct migration of the context. Lastly, a final promotion vote period decides on whether or not to activate the proposal.

Proposal execution happens automatically on the network and does not rely on execution by a trusted third-party. No single entity has executive approval and a successful proposal requires a supermajority in favor of a proposal by bakers twice.

Dispute resolution rests with off-chain interactions and social discourse. Otherwise, all proposals are either accepted or rejected through on-chain votes by bakers.

Systems of accountability for proposals rests in the multi-cycle nature of successfully including proposals and changing the Tezos protocol. Rather than a single vote, moving a proposal through the process requires four distinct periods of voting and testing. Also, thresholds for voting in favor of a proposal require high quorum thresholds to ensure sufficient support.

Tezos’ amendment process is a binding process. Systems for non-binding signals rest both with social interactions and delegation to bakers. Tezos encourages community participation in governance by proxy via delegation. As an end-user with an insufficient amount of assets to run a baker, one can delegate their holdings to a baker which they believe represents their interests. Social interactions on social media and forums can be indicators of proposal safety and serve as an implicit signaling mechanism as to whether or not something may be passed or not by bakers. Other tools for community signaling and funding (e.g. DAOs) are in development.

Currently there is only one amendment process for making upgrades to the network. In the periods of Tezos governance, there are different thresholds of acceptance. The initial proposal period allows validators to ‘upvote’ once on up to 20 proposals in order to narrow down to the 1 accepted proposal for that cycle. The exploration vote requires either an 80% supermajority or a high quorum based on participation rate. After the testing period, the promotion vote period requires either an 80% supermajority quorum or the same quorum style based on past participation rate.

Yes - changes to the Tezos shell or things like the storage layer can require a hard fork, albeit unlikely to be controversial. Emergency security patches also must be done as hard forks.

One of the core mechanisms implemented to make changes harder in order to better assess proposals is how governance is handled through four distinct periods over 3 months. By handling a single proposal at a time, having additional checks on whether the proposed upgrade would be beneficial to the platform, and having high-thresholds for passing, Tezos requires these checks to strongly encourage that only well-defined proposals get passed. The system also includes a quorum adjustment mechanism which prevents the process from becoming stuck with too high of a quorum.

A significant change to Tezos’ quorum mechanism arrived in 2019’s Babylon upgrade. This adjusted the quorum such that adjustments would more closely reflect past participation, quorum is bounded by a ceiling and a floor, and removes risk of a “swinging boat” effect in which the quorum adjustment could rise too high based on high rates of participation. 

Another revision in the past has been the amount of assets needed to become a validator on the network which directly affects the ability for individuals to participate in the governance process. This was considered and passed in order to further democratize the network via lower entry costs and expand participation. 

A new amendment proposal would adds an additional “adoption” phase or waiting period between the final vote result and activation of the new protocol. This amendment also shortens the overall amendment period. Future proposals are expected to attempt decoupling of voting rights from consensus, allowing delegators to override bakers’ votes.