Skip to main content

Tokenomics

QoreChain uses a fixed-supply economic model centered on the native QOR token. Rather than inflating the supply over time, the network funds staking rewards from a finite, pre-allocated emission budget while a multi-channel burn engine applies sustained deflationary pressure as network usage grows.


Token Basics

PropertyValue
Display tokenQOR
Base denominationuqor
Decimal precision10^6 (1 QOR = 1,000,000 uqor)
Total supply4,500,000,000 QOR (fixed)
Chain IDqorechain-vladi (mainnet, EVM chain ID 9801)
Bech32 prefixqor (accounts: qor1..., validators: qorvaloper...)
note

The figures on this page describe the mainnet (qorechain-vladi, EVM chain ID 9801), live since 7 June 2026 on chain version v3.1.85. The qorechain-diana testnet (EVM chain ID 9800) shares the same economic model.


Supply and Emission Model

QoreChain has a fixed total supply of 4,500,000,000 QOR. New QOR is never minted to inflate the supply. Instead:

  • 80,000,000 QOR (1.78% of supply) was burned at the Token Generation Event (TGE).
  • Staking rewards are paid from a finite emission budget of 590,000,000 QOR, drawn down over time on a declining schedule.

This is a fixed-supply model with a finite emission budget, not an inflation-of-supply model. Once the emission budget is exhausted, no further reward emission occurs beyond what governance allocates from the remaining budget.

Staking Reward Schedule

Staking rewards are distributed from the 590,000,000 QOR emission budget on a declining schedule:

PeriodTarget APYEmission Budget
Year 18–12% APY127,500,000 QOR
Year 26–10% APY106,250,000 QOR
Years 3–45–8% APY85,000,000 QOR per year
Year 5+Governance-determined~186,000,000 QOR remaining

APY ranges are targets that depend on the bonded ratio; the emission budget figures are the hard caps on QOR released to stakers in each period. From Year 5 onward, the remaining ~186,000,000 QOR is released at a rate set by governance.


x/burn — Multi-Channel Burn Engine

The x/burn module implements a 10-channel token burn system. Every burned token is permanently removed from circulating supply, creating sustained deflationary pressure as network usage grows.

Burn Channels

#ChannelSourceDescription
1gas_feeTransaction fees30% of all gas fees are burned
2contract_createSmart contract deploymentFlat 100 QOR fee burned per contract creation
3ai_serviceAI module usage fees50% of AI service fees burned
4bridge_feeCross-chain bridge fees100% of bridge fees burned
5treasury_buybackTreasury operationsPeriodic buyback-and-burn from treasury
6failed_txFailed transaction gas10% of gas from failed transactions burned
7xqore_penaltyxQORE early exit penaltiesPenalty amounts routed through burn
8auto_buybackAutomated buyback programProtocol-level automated burns
9tgeToken generation eventOne-time genesis burns (80,000,000 QOR)
10rollup_createRollup deployment1% of rollup creation stake burned

Fee Distribution

All transaction fees collected by the network are split across five destinations, as shown below. The shares are enforced on-chain and always sum to exactly 100%.

All transaction fees collected by the network are split across five destinations:

RecipientShareDescription
Validators37%Distributed to the active validator set proportional to stake
Burned30%Permanently removed from supply via the gas_fee burn channel
Treasury20%Allocated to the community treasury for governance-directed spending
Stakers10%Distributed to all QOR stakers proportional to delegation
Light Nodes3%Distributed to light nodes for serving network data

The shares are enforced on-chain and must always sum to exactly 100%.

Burn Parameters

ParameterDefaultDescription
gas_burn_rate0.30Fraction of gas fees burned (30%)
contract_create_fee100,000,000 uqor (100 QOR)Flat burn fee for contract creation
ai_service_burn_rate0.50Fraction of AI service fees burned (50%)
bridge_burn_rate1.00Fraction of bridge fees burned (100%)
failed_tx_burn_rate0.10Fraction of failed TX gas burned (10%)

Each burn event is recorded on-chain with its source, amount, block height, and associated transaction hash. Aggregate statistics are queryable per channel and in total.


x/xqore — Locked Staking and Governance Amplification

The x/xqore module introduces xQORE, a non-transferable locked-staking derivative. Users lock QOR to mint xQORE at a 1:1 ratio. xQORE holders receive amplified governance power and a share of redistributed exit penalties.

Lock Mechanism

  • Lock: Send QOR to the xQORE module to mint xQORE at a 1:1 ratio.
  • Governance weight: xQORE holders receive 2x governance voting power compared to standard QOR stakers.
  • Non-transferable: xQORE cannot be sent between accounts. It is bound to the locking address.

Exit Penalty Schedule

Early withdrawal from xQORE incurs a penalty that decreases with lock duration:

Lock DurationPenalty RateDescription
< 30 days50%Half of locked QOR is forfeited
30 -- 90 days35%Significant penalty for short-term locks
90 -- 180 days15%Reduced penalty for medium-term commitment
> 180 days0%Full withdrawal with no penalty

PvP Rebase Redistribution

Penalties collected from early exits are not simply destroyed. Instead, they follow a PvP (player-versus-player) rebase model:

  1. 50% of penalty amounts are burned (routed through x/burn via the xqore_penalty channel).
  2. 50% are redistributed pro-rata to all remaining xQORE holders.

This creates a positive-sum dynamic for long-term holders: every early exit increases the effective value of remaining xQORE positions. Rebases occur every 100 blocks.

xQORE Parameters

ParameterDefaultDescription
governance_multiplier2.0Voting power multiplier for xQORE holders
min_lock_amount1,000,000 uqor (1 QOR)Minimum QOR required to lock
penalty_burn_rate0.50Fraction of exit penalties burned (50%)
rebase_interval100 blocksBlocks between PvP rebase events
enabledtrueModule activation flag

x/inflation — Emission Budget Schedule

Despite its module name, the x/inflation module does not inflate the total supply. It governs the release of staking rewards from the finite 590,000,000 QOR emission budget according to the declining staking reward schedule. Emissions are computed per epoch and distributed to stakers and validators, drawing down the pre-allocated budget rather than minting new supply.

Epoch Mechanics

  • Epoch length: 17,280 blocks (~1 day at 5-second block times)
  • Blocks per year: ~6,311,520
  • At the start of each epoch, the scheduled emission for the current period is released from the emission budget and distributed to stakers and validators.
  • The epoch tracker records the current epoch number, current year, starting block, cumulative QOR released from the emission budget, and the remaining budget.

Inflation Parameters

ParameterDefaultDescription
scheduledecliningPeriod-indexed emission budget (see staking reward schedule)
epoch_length17,280 blocksBlocks per emission epoch
enabledtrueModule activation flag

Deflationary Dynamics

Because the supply is fixed and emission is drawn from a finite budget, QoreChain's net token dynamics trend deflationary as adoption grows:

Years 1-2: Larger scheduled emissions from the budget offset burns → near-neutral supply
Years 3-4: Scheduled emissions decline; burn volume grows with usage → convergence
Year 5+: Emission budget is largely drawn down; burn channels (gas, bridge,
contracts, rollups) scale with transaction volume → net deflationary

The 10 burn channels ensure that every major network activity removes tokens from supply. As transaction volume, bridge usage, AI service calls, and rollup deployments increase, cumulative burns accelerate while scheduled emissions decline toward the end of the finite budget.


Module Lifecycle Order

The economic modules execute in a specific order during each block's EndBlocker:

x/burn → x/xqore → x/inflation → x/rlconsensus
  1. x/burn — Processes pending burn records and updates aggregate statistics.
  2. x/xqore — Executes PvP rebases (every rebase_interval blocks) and routes penalties to burn.
  3. x/inflation — Releases scheduled staking-reward emissions from the budget at epoch boundaries.
  4. x/rlconsensus — Adjusts consensus parameters based on PRISM reinforcement-learning signals.

This ordering ensures that burns are finalized before rebases, and rebases complete before scheduled emissions are released, maintaining consistent economic state transitions.