Jellyverse Docs
WebsiteApp
English
English
  • Overview
    • How to Connect to SEI
    • How to get SEI Devnet Funds
    • How to make your first Swap
  • Protocol Library
    • JellySwap
      • Liquidity Management
        • Swaps
      • Pools
        • Weighted Pools
        • Stable Pools
          • Composable Stable Pools
        • Setting up a Pool Configuration
      • Impermanent Loss
        • 50/50 Pools
        • 80/20 Pools
        • Multitoken Pools
      • Preminted JPT
      • Relayers
      • Smart Order Router (SOR)
    • JellyStake
      • Staking Chests
      • Voting power
    • jAssets by BLKSWN
      • Liquidation and the Stability Pool
      • Liquidation Logic
      • Recovery Mode
      • jUSD Redemption
      • Expected User Behaviors
      • Core Smart Contracts
      • PriceFeed and Oracle
      • Contract Ownership and Function Permissions
      • Keeping a sorted list of Vaults ordered by LACR
      • Supplying Hints to Vault operations
      • Gas compensation
      • The Stability Pool
      • Swap Pools
      • Protocol System Fees
      • Governance
      • Audits
  • Jellyverse Architecture
    • Governance
    • Rewards
    • Reward Distributor
    • Tokenomics
    • Whitepaper
    • Contract Addresses
  • Audit
  • Community
    • Socials
  • COMMUNITY PROTOCOLS
    • Introduction
Powered by GitBook
On this page
  • List of configurable parameters (tbd)
  • Governance System Overview
  • Timelock
  • Proposal Lifecycle
  1. Jellyverse Architecture

Governance

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.

Timelock

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 1 year ago

Jellyverse Proposal Lifecycle