Network Fees

Constellation Network is designed to support high-throughput, low-cost applications without sacrificing decentralization or security. At the heart of this design is a flexible, modular fee system that allows most users to interact with the network for free while still supporting essential network operations, encouraging responsible usage, and enabling a scalable token economy.

Constellation’s approach to fees is guided by two core principles:

• Feeless by default, to reduce friction and support accessibility

• Fees where needed, to support network sustainability, security, and performance

This section provides an overview of how network fees function across different layers of the network, including peer-to-peer DAG transactions and metagraph activity.

---

Why Fees Exist

Unlike traditional blockchains that apply flat fees to every transaction, Constellation applies fees only when necessary. Fees serve several critical functions:

• Security: They deter abuse by making spam attacks, resource hoarding, or denial-of-service attempts economically unfeasible.

• Prioritization: Fees can be optionally included to increase the priority of certain actions, ensuring timely processing in high-demand scenarios.

• Resource Allocation: Fees are used to manage storage, computation, and bandwidth in a way that incentivizes efficient use of network resources.

• Economic Incentives: Validators and infrastructure providers are rewarded through the redistribution of fees, creating a sustainable incentive model.

• Network Subsidy: Low or zero fees act as an intentional subsidy to stimulate adoption and experimentation, particularly in the early phases of network growth.

This model creates a flexible fee economy where light users can interact freely, and heavy users or high-performance applications help fund the system.

---

L0 Token Transaction Fees

DAG and metagraph-hosted L0 tokens support peer-to-peer transactions between wallets on the DAG or Metagraph Currency L1 layer. These transactions are feeless by default, meaning users can send and receive tokens without paying a fee in most cases.

However, optional fees can be included in a transaction to:

• Prioritize it for inclusion in the next snapshot

• Trigger parallel consensus

• Bypass rate limits that apply to high-volume or low-balance accounts

This tiered system enables different levels of service based on user needs and prevents network abuse without excluding legitimate use.

Example Use Case

If a wallet needs to send hundreds of transactions quickly (e.g., for an airdrop), it can attach a small fee (e.g., 1 datum or more) to each transaction. This ensures priority processing and higher throughput, while ordinary users sending occasional transactions continue to operate for free.

Low Balance Rate Limits

To mitigate spam from wallets with negligible balances, a dynamic rate limit is applied to accounts with low DAG holdings. This limit can be bypassed by attaching a small fee (0.002 DAG) to a transaction.

This strategy ensures that wallet spam becomes prohibitively expensive, protecting network performance without disrupting typical usage patterns.

Custom Metagraph Transaction Fees

Each metagraph has the flexibility to define its own internal fee logic for transactions and services within its domain. This allows metagraphs to implement business models, incentives, and cost structures tailored to their specific use case—all while staying interoperable with the rest of the network.

Data Update Fees

Metagraphs can associate L0 token payments directly with data submissions using the FeeTransaction type. This creates a native mechanism for pay-per-use functionality, where users pay for access to specific services, datasets, or on-chain actions.

Key characteristics:

• FeeTransaction is cryptographically linked to a data submission but does not include the data itself—preserving user privacy.

• It allows metagraphs to monetize access to data, trigger logic only when payment is received, or implement rate-limiting based on fee volume.

• Transactions can be submitted atomically alongside their associated data updates, ensuring consistency between payment and action.

Custom L0 Token Fees

Metagraphs using the Euclid SDK Currency Layer can enforce minimum fee requirements on L0 token transfers. These rules can be based on custom business logic, such as:

• Fixed minimum transfer fees per transaction

• Tiered fees based on token amount or user role

• Dynamic fees based on network activity or metagraph load

• Governance-controlled fee schedules

Because metagraphs control their own business logic, they can determine when and how to charge users for token transfers, staking, or in-app utility—without requiring changes to the global protocol.

---

Snapshot Fees

While peer-to-peer usage is largely feeless, metagraphs interact with the network in more complex ways. These interactions are subject to required snapshot fees, which are currently the only mandatory fees on the network.

Who Pays

Snapshot fees are paid by metagraph operators, not end users. This allows each metagraph to determine how or whether to pass costs along to its users. Projects can cover fees themselves, subsidize usage through staking rewards or grants, or introduce custom fee models at the application level.

What Fees Pay For

Snapshot fees support:

• Global consensus validation of metagraph data

• Secure data storage by archive nodes

• Proof-of-record for any data or token activity committed to the Hypergraph

These fees are denominated in DAG and deducted from a designated metagraph fee wallet.

---

How Snapshot Fees Are Calculated

Snapshot fees are determined by the following formula:

Fee = (baseFee × WorkAmount × workMultiplier) + optionalTip

Key Inputs:

• WorkAmount: Reflects both the size (in KB) and computational complexity of the submitted data.

• WorkMultiplier: A reduction factor based on the amount of staked DAG and the metagraph’s PRO Score.

• Optional Tip: An extra fee a metagraph can include to prioritize its snapshot during network congestion.

Snapshot fees are fixed, not market-driven, which ensures predictability and easier budgeting for metagraph projects.

---

Fee Wallets and Staking

Each metagraph must designate a fee wallet to pay for snapshots and a staking wallet to qualify for reduced fees. Only DAG in the staking wallet counts toward fee reductions—collateral or DAG stored in other wallets does not.

Staking DAG:

• Reduces snapshot fees through the workMultiplier

• Signals long-term commitment to the network

• Contributes to network security by removing tokens from circulation

Fees can never be reduced to zero, but large staked balances significantly lower operational costs for active metagraphs.

---

Summary

Constellation Network’s fee model is designed for scale, flexibility, and fairness. Most everyday usage is free or extremely low-cost, while higher-intensity or system-critical operations are funded through proportional fees.

This structure:

• Encourages innovation and accessibility

• Protects the network from misuse

• Supports validator incentives and long-term sustainability

• Enables developers to launch metagraphs with flexible economic models

As the network evolves, fees will remain an essential tool—not just for paying for resources, but for shaping user behavior, securing infrastructure, and growing a healthy, decentralized economy.

For more information on network fees and their implementation, see Network Fees on the Hypergraph.