🌅
Sunrise / Gluon Docs
  • Home
    • 👋Sunrise
  • 📜Learn
    • 🌆Sunrise
      • Proof of Liquidity
      • Data Availability
      • Liquidity Pool
      • Swap
      • Liquidity Incentive
        • Gauges Voting
        • Bribes
      • TokenConverter
      • Fee
      • Lockup Account
      • Non-Voting Delegation
    • 💴$RISE
      • Allocations
    • 🏦Gluon
    • 💴$GLU
    • 🎓Thesis
      • App chain thesis
      • Interoperability
  • 🛠️Build
    • Client
    • L2 Blockchains
      • Rollkit
        • Sunrise Data
        • Rollkit L2 Chain
      • OP Stack
        • Sunrise Data
        • OP Stack L2 Chain
    • Validators
      • Proof of Data Availability
  • 🏗️Run a Sunrise Node
    • Networks
    • Types of Nodes
      • Consensus
        • Full Consensus Node
        • Validator Node (Genesis)
        • Validator Node
        • Setup Cosmovisor
      • IBC Relayers
    • Resources
      • Upgrade
      • Environment
  • 🏗️Run a Gluon Node
    • Networks
    • Node
      • Validator Node
  • 🔗Links
    • GitHub
    • Discord
    • X (Twitter)
    • Medium
Powered by GitBook
On this page
  • Key Features of x/fee
  • Core Functionality
  • Fee Collection and Processing
  • Parameter Configuration
  • Workflow: Fee Processing
  1. Learn
  2. Sunrise

Fee

The x/fee module is a core component of the Sunrise blockchain responsible for managing transaction fees. It introduces mechanisms for burning a portion of $RISE tokens used as fees, and enforcing fee denominations. This module supports deflationary tokenomics while maintaining an efficient fee system.

Key Features of x/fee

  1. Burn Mechanism:

    • A portion of $RISE tokens used as transaction fees is burned to reduce the circulating supply.

    • The burn ratio is determined by the burn_ratio parameter (default: 50%).

    • Burn operations are atomic and verified on-chain.

  2. Fee Denomination (fee_denom):

    • Specifies the denomination required for transaction fees (default: "urise").

    • Transactions must pay fees in this denomination unless bypassed.

    • Strict validation of fee denominations is enforced.

  3. Dynamic Parameter Configuration:

    • Developers can configure parameters dynamically with validation enforced by the module.

    • Parameters can be updated through governance proposals.

Core Functionality

Fee Collection and Processing

Fee Collection Process:

  1. Fees are collected through the FeeCollector module account

  2. The system validates:

    • Only one fee denomination per transaction

    • Fee denomination matches configured fee_denom

    • Fee amount is valid and non-zero

Fee Processing Flow:

  1. Validate fees against configured parameters

  2. Calculate burn amount based on burn_ratio

  3. Execute burn operation for the calculated amount

  4. Transfer remaining fees to fee collector

Parameter Configuration

Note: The following section covers advanced topics intended for experienced users or developers.

Parameter
Description
Default Value
Constraints

fee_denom

Required denomination for transaction fees

"urise"

Must be a valid denomination

burn_ratio

Percentage of fees to burn

0.5

Must be between 0 and 1

Workflow: Fee Processing

Note: The following section covers advanced topics intended for experienced users or developers.

PreviousTokenConverterNextLockup Account

Last updated 2 days ago

For more details and implementation specifics, see the .

📜
🌆
GitHub repository