> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lumera.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Protocol Economics

> How issuance, transaction fees, protocol-service revenue, and long-term sustainability work across Lumera.

Lumera's economic model coordinates four distinct functions: securing consensus, pricing block space, compensating protocol-service operators, and funding long-lived network obligations.

Newly issued LUME rewards validators and delegators for securing the network. Transaction fees compensate block producers while permanently removing a portion of supply. Protocol-service fees are paid by applications requesting work and earned by the SuperNodes that perform it. Everlight supports obligations—such as permanent data retention—that continue long after an individual service request has settled.

| Economic flow          | Source                                            | Primary recipients                               | Purpose                                                  |
| ---------------------- | ------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------- |
| Block Rewards          | Newly issued LUME                                 | Validators and Delegators                        | Secure consensus and maintain a target bonded ratio      |
| Transaction Fees       | Gas paid on transactions                          | Validators and Delegators, with a portion burned | Price block space, deter spam, and offset issuance       |
| Protocol-Service fees  | Payments for executing Actions                    | SuperNodes                                       | Compensate operators that provide decentralized services |
| Sustainability Funding | Protocol reward flows, fee shares, and endowments | Eligible service operators                       | Fund long-lived protocol obligations                     |

## Block Rewards

Newly issued LUME is distributed each block to validators and their delegators in exchange for securing consensus. Issuance is adaptive rather than fixed: it increases when the bonded share of supply falls below the protocol's target and decreases when staking participation exceeds it. See [LUME supply mechanics](/token).

| Allocation                | Share |
| ------------------------- | ----- |
| Validators and delegators | 98%   |
| Community pool            | 2%    |

The community pool supports protocol development, ecosystem initiatives, and other governance-approved expenditures.

## Transaction Fees

The burn creates a direct link between network activity and LUME supply. As transaction volume increases, more LUME is permanently removed from circulation, partially offsetting the dilution created by security issuance.

| Allocation                | Share |
| ------------------------- | ----- |
| Validators and delegators | 80%   |
| Burned                    | 20%   |

The burn is the network's deflationary link to usage: the more the chain is used, the more LUME is permanently destroyed. This is not a fixed emission schedule running independently of activity. It responds to it.

## Protocol-Service Fees

Protocol-service fees are Lumera's demand-driven economic flow. They are paid by applications requesting decentralized services and earned by the SuperNodes that perform and verifiably complete the work.

**Who pays.** Users, developers, smart contracts, and applications that request protocol Actions. Fees are established when an Action is registered, escrowed on-chain, and released according to the service's completion and settlement rules.

**Who earns.** SuperNodes earn fees for the protocol services they successfully provide. Service revenue is distinct from staking rewards: operating a SuperNode is an independent economic activity requiring infrastructure, availability, and service-specific capabilities.

**How fees are calculated.** Each protocol service prices the resources and obligations it consumes. Pricing may reflect data size, execution requirements, verification costs, duration, or other service-specific factors established by protocol parameters.

### Example: Cascade Pricing

Cascade uses a base registration fee plus a size-based component reflecting the amount of data placed into permanent storage.

| Component               | Basis                                                                     |
| ----------------------- | ------------------------------------------------------------------------- |
| **Base fee**            | Charged when the storage Action is registered                             |
| **Size-based fee**      | Calculated from the amount of data stored                                 |
| **Long-term retention** | Supported through Everlight rather than recurring charges to the uploader |

Current parameters are queryable on-chain and adjustable through governance. See [How Cascade Works](/cascade/how-cascade-works) for current pricing and lifecycle details.

### Keeping Service Pricing Competitive

Protocol-service pricing must account for two competing requirements: services should remain commercially competitive for users, while operator compensation must remain sufficient to support reliable infrastructure.

Where enabled by a service's pricing model, a **dynamic adjustment factor** can reduce the effect of changes in LUME's market value on real-world service pricing. Without such an adjustment, services denominated entirely in an appreciating native asset could become increasingly expensive relative to centralized alternatives.

A separate **base-cost adjustment** can account for changes in the real-world expenses operators bear, including hardware, storage, bandwidth, and power. Together, these mechanisms are intended to preserve affordable service pricing without undermining the economics required to retain capable operators.

## Sustainability and Everlight

Some protocol services create obligations that outlive the transaction that created them. Permanent storage is the clearest example: a single upfront payment must support data retention long after the original Action has settled.

Per-use service fees and long-term sustainability funding therefore serve different economic purposes. Service fees compensate operators for completing immediate work. **Everlight** supports persistent obligations by directing protocol reward flows, registration-fee shares, and endowment yield toward eligible operators over time.

SuperNodes must continue proving that required data remains available to remain eligible for retention compensation. Permanence is therefore supported by ongoing economic incentives and cryptographic evidence rather than by a contractual promise from a centralized company.

Everlight provides the model for funding other long-lived protocol obligations as Lumera expands, including persistent artifacts, service availability, and additional infrastructure that cannot be sustained through one-time execution fees alone. See [Everlight](/cascade/everlight/overview).

## How the Economic Flows Interact

Lumera's economic flows are designed to reinforce one another while serving distinct purposes.

Security issuance rewards validators and delegators for maintaining consensus, but increases circulating supply. Transaction-fee burns offset a portion of that issuance in proportion to network activity. Protocol-service fees compensate the SuperNodes that provide capacity, allowing infrastructure supply to grow in response to application demand rather than relying solely on higher token issuance.

Everlight closes the remaining gap by funding obligations that persist after an individual Action settles. This prevents permanent services from accumulating unfunded liabilities and allows one-time service payments to support long-lived outcomes.

The resulting loop connects usage directly to network capacity and economic security: applications consume services, fees compensate operators, increased demand attracts additional capacity, and transaction activity removes a portion of LUME from circulation.

### Illustrative Cascade Transaction

<Info>
  At current parameters, a Cascade Action includes a base fee of `10,000 ulume` plus `10 ulume` per KB, placing a 1 MB upload at approximately `0.02 LUME`.

  The service fee is escrowed when the Action is registered and released according to the Cascade settlement lifecycle. The registration transaction also incurs gas, of which 80% is distributed to validators and delegators and 20% is burned. Everlight subsequently supports the network's ongoing retention obligation.

  These figures are governance-controlled protocol parameters and may change. Query the network or refer the [Cascade documentation](/cascade/how-cascade-works) for current values.
</Info>

<CardGroup cols={3}>
  <Card title="LUME Token" icon="coins" href="/token">
    Understand token utility, supply mechanics, staking, and burns.
  </Card>

  <Card title="Run a SuperNode" icon="server" href="/quickstart-supernode">
    Provide protocol services and earn service fees.
  </Card>

  <Card title="Governance" icon="landmark" href="/governance">
    Learn how economic parameters and fee structures are governed.
  </Card>
</CardGroup>
