A truly decentralized Governance system

The Jellyverse Governance model aims to empower users to guide protocols within the Jellyverse ecosystem in the right direction. It also provides new projects with the option to integrate into Jellyverse. This approach offers several significant advantages, as Jellyverse is known for its sustainable, robust, and scalable system. This system allows for the equitable distribution of protocol revenues to stakers, making it a promising choice for projects looking to thrive.

When new projects decide to integrate into the ecosystem, certain adjustments may be necessary, particularly in areas like reward distribution. It's essential to note that governance authority is limited to configurable parameters exclusively.

List of configurable parameters (tbd)

Governance System Overview

A proposal is essentially a collection of transactions. Front-end providers can design user-friendly interfaces to simplify navigation and facilitate interaction with the governance system.

To establish a genuinely decentralized governance system, every address is eligible to function as both a Proposer and an Executor. To aid comprehension, these roles are clearly outlined in the documentation.

  • Proposers schedule and cancel operations.

  • Executors execute operations once the timelock has expired.

This governance model will be seamlessly integrated using OpenZeppelin's smart contracts. In this framework, JLY tokens will serve as the default voting mechanism. This modular system will comprise the following components:

  • JellyToken.sol

  • JellyGovernance.sol

  • JellyTimelock.sol

  • JellyChest.sol

During deployment, initiators will configure parameters for the following variables:

  • Voting Delay (in blocks) - The minimum number of blocks that must pass between the time a proposal is created and the time it can be voted on.

  • Voting Period (in blocks) - The number of blocks that a proposal has to be voted on.

  • Proposal Threshold - The minimum number of votes required for an account to create a proposal.

  • Quorum - The minimum number of votes required for a proposal to pass.

  • MinDelay - The minimum number of seconds that must pass before an operation can be performed. This can be zero.


The Timelock feature is not obligatory but rather optional, as the minimum delay for execution can be set to 0 or a minimal value. It introduces a time delay between the submission of a proposal and its execution, thereby providing an additional layer of security and allowing the community to opt-out if they disagree with the accepted proposal. Timelocked operations are uniquely identified by their hash and follow a predefined lifecycle:

Proposal Lifecycle

Each proposal must adhere to a predefined lifecycle to guarantee that the Jellyverse community has adequate time to review and assess it. Once a proposal is approved, it becomes irreversible and cannot be halted. Throughout its lifecycle, a proposal can be in one of the following states:

The proposal can be in one of the following states:

  • Pending - The proposal has been created, but not yet voted on.

  • Active - The proposal has been created and is being voted on.

  • Canceled - The proposal has been created but was canceled before it was voted on.

  • Defeated - The proposal has been created and voted on but did not pass.

  • Succeeded - The proposal has been created, voted on, and passed.

  • Queued - The proposal has been created, voted on, and passed, and is waiting to be executed.

  • Expired - The proposal has been created, voted on, and passed, but has not been executed before the GRACE_PERIOD. Placeholder value.

  • Executed - The proposal has been created, voted on, passed, and executed.

Last updated