Skip to main content
Note: the Grid’s fee model described here is a design under active development. The network does not yet charge fees on DevNet. This page documents the intended model so integrators can plan against it; expect details to evolve before mainnet.

​
The cost problem on other chains

On most blockchains, the dollar cost of a transaction is straightforward: 
cost = gas_units × base_fee × native_token_price
EIP-1559 style mechanisms can smooth the base_fee component over time, but they cannot smooth native_token_price. An application that transacts frequently is exposed to volatility unrelated to its computational workload. A spike in the price of the native gas token can make tomorrow’s batch of operations cost ten times what today’s did, breaking budgets and making cost planning impossible.

​
Stablecoin-denominated fees

The Grid’s fee model is designed so transaction fees can be paid directly in a stablecoin chosen by the signer. There is no separate volatile native gas token to acquire, hold, or hedge against. The fee is denominated in the same unit of account the application already operates in. When fees are active, an activation will deduct fees from the signer’s balance in their chosen stablecoin. A finance team can budget the application in dollars and audit its spend in dollars. Price volatility of an unrelated asset cannot change tomorrow’s cost.

​
Per-component metering

The Grid is built on the actor model. Each component owns its own state and processes work independently. The cost of a multi-step workflow is the sum of well-defined component-level costs rather than an opaque aggregate charged against a shared global context. When fees are charged, each component’s portion of the work will have a measurable, isolated cost. This makes it possible to reason about the economics of a workflow: you can estimate the cost of each step and add them up, rather than guessing how the transaction will interact with global state and other concurrent work.

​
Capacity-based, not purely auctioned

The Grid’s gas model is intended to be capacity-based rather than purely auction-driven. Applications will be able to reserve execution capacity for critical operations, so payment flows retain predictable cost and throughput even when other parts of the network are under load. This is particularly important for agent payments, where a burst of small high-value transactions must not be priced out by unrelated network congestion.

​
Multi-resource gas dimensions

Even before fees are metered economically, every activation result already exposes gas used along three independent dimensions:
  • cpu: compute work performed (operations executed, function calls made).
  • network: cross-component message bandwidth (bytes of inter-component communication).
  • storage_io: reads and writes against shard-local state.
These dimensions are visible today in the gas_used field of an activation result. For example: 
{
  "gas_used": { "cpu": "0", "network": "0", "storage_io": "0" }
}
You can see this in the output of gen client get-activation. The shape of this data structure is stable and will not change when fees ship.

​
What changes when fees ship

The structure and semantics of gas_used will remain the same. What will change is that each dimension will translate into a fee in the stablecoin you specified, deducted from your balance. Applications building on the Grid today can read gas_used from every activation to estimate the cost your workflows will incur once fees are active. This lets you stress-test your economics and validate that your unit prices remain viable.