Valueverse
  • Screener
  • Research
Valueverse

Token cash-flow data, value mechanics, and API access for research workflows.

Platform

  • Screener
  • Research
  • Sign in
  • Account

Developers

  • API docs
  • API keys

Resources

  • FAQ
  • Methodology
  • Updates

Legal

  • Terms of Use
  • Privacy Policy
© 2026 Valueverse. All rights reserved.Built for token fundamentals, mechanics, and tester APIs.
Sign in
Back to Gnosis
Overview
Mechanism map
Governance Token
Delegated Governance
Consensus Token
Gnosis

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 voting
  • user_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:

r(x)=1 year⋅F⋅32⋅109S⋅T⋅(x+N)⋅32⋅109r(x) = \frac{1\ year\cdot F \cdot 32\cdot10^9 }{S\cdot T\cdot\sqrt{(x+N)\cdot 32\cdot 10^9}}r(x)=S⋅T⋅(x+N)⋅32⋅109​1 year⋅F⋅32⋅109​

f(x)=1 year⋅F⋅100S⋅T⋅(x+N)⋅32⋅109f(x) = \frac{1\ year\cdot F \cdot 100 }{S\cdot T\cdot\sqrt{(x+N)\cdot 32\cdot 10^9}}f(x)=S⋅T⋅(x+N)⋅32⋅109​1 year⋅F⋅100​

Where:

  1. The reward factor F=25F = 25F=25
  2. The slot time T=5T = 5T=5
  3. The epochal number of slots S=16S = 16S=16
  4. The initial validator set size N=4096N = 4096N=4096
  5. xxx is the amount of GNO staked (i.e., roughly the number of operational validators)
  6. rrr is the amount of GNO rewards in an epoch
  7. fff 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:

  1. The GIP draft is created on the forum
  2. Community engages in discussion of the proposal
  3. 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.
  4. If the proposal passes the temp check, it proceeds to the stage of a weeklong vote at the Gnosis Snapshot space.
  5. 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.

Value drivers

Conditional Action

represents voting power delegation

Reflects delegation of voting power within the framework of Gnosis DAO. Note that this does not imply delegation of GNO stake, which does not exist natively.

[82] = Binary

Governance

represents extraction of indirect governance participation value

Represents extraction of tangible and/or intangible governance value derived from voting power delegation, i.e., the realisation of indirect governance participation.

[31] = ƒ([82], delegate_vote_allocations, user_strategy_representation)

  • delegate_vote_allocations — is the representation of allocations of votes by the user's delegate during the voting
  • user_strategy_representation — is the representation of the user's governance outcome preferences

Consensus Token

Represents GNO's functionality as a medium of staking value in order to drive the security of the Gnosis Chain by securing validator operation and by creating an economic incentive to operate said validators.

Value drivers

Transferability Restriction

represents staking GNO in order to gain access to validator running

Reflects the staking of GNO (at least 1 GNO) in order to qualify for operation of a validator (or a number thereof). This exposes the GNO to a risk of runaway depreciation and, in case of non-exited validators, also the risk of slashing (note that while Gnosis Chain's docs follow Ethereum's model in specifying slashing as one of several tiers of token-alienating penalties, we denote all such penalties as slashing in order to preserve internal consistency). When a full withdrawal (see the VCIP section) is triggered, a variable delay may be imposed on the withdrawal because withdrawals are processed via a queue, and, as such, this may impose delays, especially when the payout contract used to disburse GNO back temporarily lacks funds.

Note that liquid staking options are available for GNO holders, but they are offered by external parties and therefore do not constitute parts of GNO token design.

[7] = ƒ(staking_period, amount_staked, price_at_staking)

  • staking_period — is the length of the lock-up period set up by the user
  • amount_staked — is the amount of tokens locked up by the user
  • price_at_staking — is the price of the locked token position when locking them. It defines the locked value (the upper bound of forfeited value) together with the locked amount

Conditional Action

represents operation of Gnosis Chain validator nodes

Reflects reliable operation of a Gnosis Chain validator with the requisite uptime metrics.

[81] = Binary

Cashflow

represents reception of validator rewards

Reflects reception of rewards due to a properly operating Gnosis Chain validator. The rewards, roughly speaking, scale as an inverse square root of the number of validators (for a truer description, please refer to the VCIP section). Note that these rewards are not conditioned explicitly on the performance of the node and only depend on it implicitly thanks to the penalisation system in place.

[2] = ƒ(total_gno_staked)

  • total_gno_staked — is the total amount of GNO staked