Gnosis
Mechanism map
- Governance Token
- Delegated Governance
- Consensus Token
Token functions
Governance Token
Represents value derived from controlling the decision-making in the Gnosis DAO by directly voting on GIPs. No staking is required to obtain voting power.
Value drivers
Conditional Action
represents directly participating in the governance
Represents participation in the voting process of the Gnosis DAO Governance.
[83] = Binary
Governance
represents value derived from influencing the outcome of voting on GIPs (i.e., the direct influence on the direction of evolution for the Gnosis ecosystem)
Reflects the value originating from participating in decicision-making in the Gnosis DAO Governance. The scope of governance is not formally limited and is encompassed by the extant and potential Gnosis Improvement Proposals.
[32] = ƒ([83], user_vote_allocations, user_strategy_representation)
user_vote_allocations— is the representation of allocations of votes by the user during the votinguser_strategy_representation— is the representation of the user's governance outcome preferences
Delegated Governance
Represents value derived from indirectly influencing the decision-making in the Gnosis DAO by delegating the voting power (without GNO alienation) to a suitable representative.
Value capture investment profile

1. CONSENSUS TOKEN IMPLEMENTATION
The user who wishes to run a validator (or a number thereof - batch staking is permitted) configures his execution and consensus clients and deposits GNO by invoking the batchDeposit method of the GNO Deposit contract, passing validator information along. After a delay meant to finalise the deposit by building a chain of subsequent blocks, the validators are added to the pool and permitted to perform work by proposing and attesting to blocks.
For each epoch that the validator is online and working, it receives GNO rewards according to a reward curve and also xDAI transaction fees. Other sources of GNO rewards are attestation and proposal fees.
The reward curve (est. by GIP-16) reads:
Where:
- The reward factor
- The slot time
- The epochal number of slots
- The initial validator set size
- is the amount of GNO staked (i.e., roughly the number of operational validators)
- is the amount of GNO rewards in an epoch
- is the epochal APY
Misbehaving nodes are subject to punishment. Slashing is the most serious sanction, which entails burning 1/32nd of a validator's stake and immediate initiation of validator removal. It is reserved for offences like double voting or double signing.
Offline penalties are exacted every time the validator does not propose/attest to blocks in a timely manner. Most of these penalties are in the form of losing the associated reward, but missing the target and source votes incurs a penalty equal to the rewards the attester would have received had they submitted them (in addition to refusing the reward).
If a large number of validators are offline concurrently, Gnosis enters the inactivity mode, in which offline validators are increasingly penalised in order to eventually eject them from the validator set and re-enable finalisation. The cutoff for ejection is 0.5 GNO (not 1 GNO, despite it being the mandatory initial stake, meaning that the validator has a margin of error of at least 0.5 GNO).
Claiming of rewards is done through the same Deposit contract as staking by invoking the claimWithdrawal method or its corresponding batch version. This also performs a partial withdrawal by skimming all GNO above 1 GNO. Full withdrawals are only available if the validator signs and broadcasts a voluntary_exit() message, in which case, all GNO is withdrawn. If the deposit/withdrawal contract temporarily lacks GNO, queued withdrawals are retried once topped up and drained at a fixed rate.
2. GOVERNANCE AND VOTING POWER DELEGATION IMPLEMENTATION
The two primary modes of Gnosis DAO governance are the forum and the Snapshot space, where the former is responsible for creation and refinement of the Gnosis Improvement Proposals (aka GIPs), and the latter - for voting on those proposals.
The lifecycle of a GIP is as follows:
- The GIP draft is created on the forum
- Community engages in discussion of the proposal
- If the proposal gains enough traction, it advances to the temperature check stage. At this stage, the detailed GIP is created as well. The temp check is done via the forum polls which remain open to voting for at least 5 days.
- If the proposal passes the temp check, it proceeds to the stage of a weeklong vote at the Gnosis Snapshot space.
- If a quorum of 75,000 GNO is reached (abstained voters are not counted towards it), and the majority of votes is in favour of the proposal, it passes and is implemented acc. to its contents.
Those of the users who would rather not vote themselves but still wish to exercise a measure of influence on the development of the ecosystem may delegate the voting power conferred by their GNO by using the Snapshot's inbuilt delegation feature.
3. MISCELLANEA
Broadly speaking, burning of GNO had been enshrined since GIP-36 in 2022 that created a commitment to bring the total supply down to 3M GNO. It is not, however, a well-formalised process, being instead carried out through dedicated GIP clauses (see the recent GIP-116 that mandated, among other things, the burning of 3.15M GNO from the vesting contract) and is therefore not included in the token's origins of value.
The reader, however, is informed that the token does possess a driver of deflationary appreciation, even if it is fairly ad-hoc in nature.
Liquid staking of GNO is provided by Stakewise. It is a third-party resource and therefore out of scope of this token page. The reader who desires to learn of it is directed to the Gnosis docs on the subject.