> For the complete documentation index, see [llms.txt](https://clubmos.gitbook.io/clubmos-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://clubmos.gitbook.io/clubmos-docs/clubmos-documentation/cmx-chain-validator-reward-and-fee-burn-policy.md).

# CMX Chain – Validator Reward & Fee Burn Policy

### 1. System Overview

CMX Chain operates under a validator-based consensus architecture where block rewards and transaction fees are distributed according to standard IBFT proposer logic.

However, validator-level reward treatment differs based on operator classification.

The protocol distinguishes between:

* Core-operated validators (managed by the CMX Core entity)
* Independent third-party validators

#### Core Policy Principle

Validators operated by the Core entity:

* Do not retain block rewards
* Do not retain transaction fees
* Burn 100% of earned rewards and fees

Independent validators:

* Retain block rewards
* Retain transaction fees
* May voluntarily implement burn policies

This architecture introduces a **validator-level emission control layer** without modifying the base reward formula at the protocol level.

The monetary supply remains algorithmically defined, while effective emission becomes dynamically elastic.

***

## 2. Consensus & Block Production Parameters

#### Consensus Mechanism

IBFT (Istanbul Byzantine Fault Tolerance)

IBFT ensures:

* Immediate block finality
* Deterministic validator rotation
* Byzantine fault tolerance
* No probabilistic fork resolution

#### Network Parameters

* Block Time: 2 seconds
* Block Reward: 0.001 CMX

#### Nominal Gross Emission Rate

Given:

Block Reward=0.001 CMXBlock\ Reward = 0.001\ CMXBlock Reward=0.001 CMX

Blocks per minute:

602=30 blocks\frac{60}{2} = 30\ blocks260​=30 blocks

Emission calculation:

0.001×30=0.03 CMX per minute0.001 \times 30 = 0.03\ CMX\ per\ minute0.001×30=0.03 CMX per minute 1.8 CMX per hour1.8\ CMX\ per\ hour1.8 CMX per hour 43.2 CMX per day43.2\ CMX\ per\ day43.2 CMX per day

This represents **theoretical gross issuance**, assuming no burn activity.

***

## 3. Reward Distribution Flow (IBFT Proposer Logic)

For each finalized block:

#### Step 1: Block Reward Computation

block\_reward=0.001 CMXblock\\\_reward = 0.001\ CMXblock\_reward=0.001 CMX

#### Step 2: Gas Fee Aggregation

total\_gas\_fees=∑(gas\_used×gas\_price)total\\\_gas\\\_fees = \sum (gas\\\_used \times gas\\\_price)total\_gas\_fees=∑(gas\_used×gas\_price)

#### Step 3: Total Validator Reward

total\_reward=block\_reward+total\_gas\_feestotal\\\_reward = block\\\_reward + total\\\_gas\\\_feestotal\_reward=block\_reward+total\_gas\_fees

The total reward is transferred to the proposer validator address.

This follows standard IBFT execution logic without modification.

***

## 4. Core Validator Burn Execution Layer

For validators operated by the Core entity:

Immediately after reward distribution:

burn\_amount=block\_reward+total\_gas\_feesburn\\\_amount = block\\\_reward + total\\\_gas\\\_feesburn\_amount=block\_reward+total\_gas\_fees

The full reward is permanently removed from circulation.

***

### Burn Execution Methods

Burn may occur through:

1. Transfer to an irrecoverable burn address (e.g., `0x000...dead`)
2. Invocation of a protocol-level `burn()` function
3. Automated treasury-burn execution logic

All burns are:

* Deterministic
* On-chain executed
* Cryptographically verifiable
* Non-reversible

Core-operated validator addresses do not accumulate rewards.

***

## 5. Dynamic Supply Impact Model

Define:

* VtotalV\_{total}Vtotal​ = Total active validators
* VcoreV\_{core}Vcore​ = Number of Core-operated validators
* PcoreP\_{core}Pcore​ = Proportion of blocks produced by Core validators

Pcore=BlockscoreTotal BlocksP\_{core} = \frac{Blocks\_{core}}{Total\ Blocks}Pcore​=Total BlocksBlockscore​​

***

### Gross Emission

gross\_emission=block\_reward×total\_blocksgross\\\_emission = block\\\_reward \times total\\\_blocksgross\_emission=block\_reward×total\_blocks

***

### Net Emission

net\_emission=gross\_emission×(1−Pcore)−gas\_fees\_burned\_by\_corenet\\\_emission = gross\\\_emission \times (1 - P\_{core}) - gas\\\_fees\\\_burned\\\_by\\\_corenet\_emission=gross\_emission×(1−Pcore​)−gas\_fees\_burned\_by\_core

***

### Deflationary Threshold Condition

If:

Pcore=1P\_{core} = 1Pcore​=1

Then:

net\_block\_reward\_emission=0net\\\_block\\\_reward\\\_emission = 0net\_block\_reward\_emission=0 net\_supply\_change=−total\_gas\_feesnet\\\_supply\\\_change = - total\\\_gas\\\_feesnet\_supply\_change=−total\_gas\_fees

Under this condition, the chain becomes:

> Strictly deflationary

***

### Partial Validator Participation Scenario

If:

0\<Pcore<10 < P\_{core} < 10\<Pcore​<1

Then:

* Block reward emission scales proportionally
* Fee burn scales proportionally
* Net supply becomes dynamic

This creates a **validator-participation-weighted emission model**.

***

## 6. Monetary Elasticity Layer

The burn mechanism introduces **monetary elasticity** tied to validator composition.

Emission is no longer static.

Effective inflation rate becomes:

Effective Inflation=Net EmissionCirculating SupplyEffective\ Inflation = \frac{Net\ Emission}{Circulating\ Supply}Effective Inflation=Circulating SupplyNet Emission​

As Core validator proportion increases:

* Inflation decreases
* Deflation probability increases
* Supply discipline strengthens

***

## 7. Transaction Fee Deflation Channel

All gas fees generated by Core-operated validators are burned.

Let:

Ft=Total gas fees at time tF\_t = Total\ gas\ fees\ at\ time\ tFt​=Total gas fees at time t

If Core produces percentage PcoreP\_{core}Pcore​:

Burned Fees=Ft×PcoreBurned\ Fees = F\_t \times P\_{core}Burned Fees=Ft​×Pcore​

Higher network usage therefore increases:

* Burn rate
* Deflationary pressure
* Supply contraction velocity

This ties monetary contraction directly to network activity.

***

## 8. Transparency & Auditability Framework

Observers can independently verify:

* Block proposer identity
* Reward transfer events
* Burn transactions
* Net circulating supply change

Verification sources:

* Block explorer data
* On-chain event logs
* Reward transfer records
* Burn address balances

No opaque treasury offsets or manual accounting is required.

All mechanics are self-verifiable.

***

## 9. Economic & Governance Implications

This architecture produces:

#### 1. Supply Discipline Without Emission Modification

Base emission remains constant, but effective supply adapts dynamically.

#### 2. Incentivized Decentralization

Higher third-party validator participation increases reward retention.

#### 3. Usage-Driven Deflation

Higher transaction volume → higher gas burn → stronger contraction.

#### 4. Monetary Policy Through Validator Composition

Supply elasticity becomes partially determined by validator structure.

***

## 10. Structural Advantages

Compared to fixed-emission or governance-modified supply models, this approach:

* Avoids sudden emission halving events
* Avoids discretionary monetary policy
* Avoids unpredictable governance-driven minting
* Maintains validator incentives
* Enables gradual, measurable emission reduction

***

## 11. Strategic Outcome

The Validator Reward & Fee Burn Policy integrates:

Consensus Participation → Monetary Policy → Supply Discipline

This ensures that:

* Network activity strengthens scarcity
* Core validator participation strengthens deflation
* Decentralization balances emission
* Monetary contraction is transparent

CMX supply dynamics are therefore:

> Deterministic at base layer\
> Elastic at validator layer\
> Transparent at execution layer