QUBIC BLOG POST
Execution Fees Are Now Live on Qubic: What You Need to Know
Written by

The Qubic Team
Published:
Jan 20, 2026
Listen to this blog post
Smart contracts on Qubic have changed.
As of January 14, 2025, contracts now pay for the computational resources they actually consume.
The update was first validated in a live testnet environment, then rolled out to mainnet, introducing organic burn directly proportional to the work a contract performs.
Why Execution Fees Matter
Every smart contract on Qubic maintains an execution fee reserve, essentially a prepaid balance that covers its compute costs.
When that reserve is depleted, the contract doesn’t disappear, but it does go dormant. It can still receive funds and respond to basic system events, however its core functions can’t be called again until the reserve is replenished.
Previously, a contract only needed a positive balance to remain active. The system verified that a reserve existed, but execution costs were not deducted based on actual computation. That has now changed. Contracts are charged proportionally to how long their procedures take to execute, aligning fees directly with real computational work.
How the System Works
The fee mechanism operates in phases, each lasting 676 ticks. Here's the process:
Execution and Measurement: When computors run your contract's procedures, they measure how long each execution takes.
Accumulation: These measurements build up over a complete 676-tick phase.
Consensus: Computors share their measured values through special transactions. The network aggregates these reports and uses the two-thirds percentile to determine a fair, agreed-upon execution fee.
Deduction: The consensus fee gets subtracted from the contract's reserve in the following phase. This phase-based approach keeps consensus efficient while ensuring accuracy across the network.
Phase n-1 Phase n Phase n+1
(676 ticks) (676 ticks) (676 ticks)
│ │ │
└── Fees computed ─┘── Fees deducted ───┘
Who Pays for What
The system follows a simple principle: whoever initiates an action pays for it. When a user calls a contract procedure, that contract's reserve covers the cost. When Contract A calls Contract B, Contract B's reserve gets checked before execution proceeds.
Some operations remain free of execution fee checks:
Operation | Fee Check |
User procedure calls | Yes |
Contract-to-contract procedures | Yes |
Contract-to-contract functions | Yes |
System callbacks (transfers, etc.) | No |
Read-only functions | No |
Epoch transitions | No |
Functions that only read data never cost anything. They provide access to contract state without modification, so they run regardless of reserve status. For more details on how procedures and functions differ, see the QPI documentation.
What Builders Should Do
If you maintain a smart contract on Qubic, consider these steps:
Review your reserve status. Check contracts.qubic.tools to see current fee consumption for your contract based on execution patterns. You can also monitor contract activity through the Qubic Explorer.
Examine your procedures. Code that returns early, uses fewer resources. Procedures that loop excessively or repeat redundant operations will cost more.
Plan for sustainability. Contracts can replenish their reserves through the qpi.burn() function or through QUtil's BurnQubicForContract procedure. You can execute these operations using the Qubic CLI. It is recommended that you ensure your contract includes a reliable mechanism for maintaining adequate reserves throughout its lifecycle.
Handle errors gracefully. When calling other contracts, check whether those calls succeeded. If a target contract has insufficient fees, your call will fail and return an error code. Build in fallback logic where appropriate.
For developers new to building on Qubic, the smart contract development guide provides a solid starting point.
What Computors Should Know
Computors have a new configuration option: the execution fee multiplier. This setting converts raw execution time into fee amounts. The network reaches consensus using the two-thirds percentile of all computor-submitted values, preventing any single operator from dramatically shifting costs.
For more information about running a computor, refer to the computor documentation.
Refilling Reserves
Three methods exist for adding to a contract's execution fee reserve:
Internal burning: Contracts can call qpi.burn(amount) to convert collected fees into reserve balance. They can also fund other contracts using qpi.burn(amount, targetContractIndex).
External contributions: Anyone can send funds to the QUtil contract's BurnQubicForContract procedure, specifying which contract should receive the reserve boost.
Legacy method: QUtil's BurnQubic procedure adds specifically to QUtil's own reserve.
These mechanisms tie directly into Qubic's tokenomics, where burning serves as the core deflationary mechanism rather than traditional transaction fees.
Protection for Users
The system includes built-in safeguards. If you send a transaction to a contract with depleted reserves, any attached funds are automatically returned. You won’t lose money because a contract failed to maintain its balance.
Read-only queries remain available even for dormant contracts. You can check its state at any time, but state-changing procedures won’t run until the reserve is replenished.
What This Means for Qubic
This update marks a meaningful shift in how Qubic handles smart contract economics.
Contracts that perform more work, pay more. Efficient code becomes genuinely valuable. And the network gains a sustainable mechanism for burning tokens tied to actual utility rather than arbitrary fixed amounts.
If you build on Qubic and haven't yet reviewed your contracts under this new model, now is the time. For technical details, see the full reference documentation on GitHub.
Join the Qubic Discord or Telegram community to ask questions, share ideas, and discuss implementation strategies with other builders.
