Skip to main content
Note: the Grid’s fee model described here is 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 Grid’s fee model prices the resources an activation consumes and charges for them, so the network can recover the cost of execution and resist spam. It is built to keep that cost fixed and predictable, independent of congestion elsewhere on the network.

​
The cost problem on other chains

On most chains, gas pricing is the congestion lever: when capacity grows scarce, the cost of gas climbs to price out demand until usage falls back to match supply. What an application pays then depends on unrelated activity elsewhere on the network, so tomorrow’s batch of operations can cost several times what today’s did, making cost planning impossible.

​
Fixed gas pricing

The Grid is designed around a fixed unit gas price. That price does not depend on how busy the network is: two activations that consume the same gas pay the same network charge, regardless of when or where they run. For an application running on the Grid, this means cost is a function of the executed work and nothing else: you can estimate an operation once and trust that estimate to hold. Fees are also denominated in stablecoins, so there is no separate volatile native gas token to acquire, hold, or hedge against, and a finance team can budget and audit spend in dollars.

​
What makes fixed pricing possible

The Grid can hold the price fixed because its execution capacity scales horizontally. On most chains, price is the only lever for rationing scarce capacity: when capacity can’t grow, the network has to price demand out until it matches supply. Because the Grid can add capacity to meet demand instead, it doesn’t need price to do that rationing. Scaling isn’t instant, though, so for work that needs guaranteed throughput the moment it’s needed — before new capacity comes online — the Grid offers advance reservation: an application claims the capacity it needs up front, and the network guarantees it’s there when called. It works like reserving instances from a cloud provider: you pay ahead for a guaranteed allocation instead of competing for whatever capacity is free at the moment you need it. Reservation sets priority, not price. Work that doesn’t reserve still runs on whatever capacity is spare, at the same fixed gas price; under a demand spike it degrades gracefully, getting slower rather than more expensive.

​
Per-component metering

Because each component owns its state and runs independently, gas is metered per component: the component that handles an activation is charged for the work that activation performs, rather than the whole trace of a cross-component workflow being billed to a single payer. This locality is deliberate. In an asynchronous trace the caller can’t know up front how the downstream work will unfold, since it depends on the future state of other components. A caller-pays model would therefore require orchestrating gas payment across a tree of continuations whose shape isn’t known in advance, which is a very complex task. Charging each component for its own work removes that burden. Applications that still want caller-pays, closer to web3’s single-payer convention, can require callers to attach funds to the activations they trigger. When fees are charged, each component’s portion of a workflow has a measurable, isolated cost, so a workflow’s total is the sum of the charges at each component it touches.

​
Multiple resources, one gas figure

Resource use is metered along three independent dimensions, each visible today in the gas_used field of an activation result:
  • 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.
For pricing, these dimensions are combined into a single gas figure that the fixed unit price applies to. They remain individually visible, so you can see what is driving a given cost. For example:
You can see this in the output of gen client get-activation.

​
What changes when fees ship

The structure and semantics of gas_used will remain the same. What will change is that the combined gas figure will translate into a fee at the fixed unit price, charged to the component that handles the activation. You can read gas_used from every activation today. The gas unit price is not yet set, so for now you can compare the resource use of different activations rather than estimate their eventual cost — enough to find your most expensive operations and optimize them before fees are active.

​
Application-layer pricing

The fixed unit gas price is what the network charges. On top of it, applications set their own pricing, charging, and admission through their Application-Controlled Execution (ACE) policy. An entry point can require a caller to attach payment before it does any work, in any token and any amount the application chooses, not necessarily matching the network charge. This is how an application can recover costs from its users without the network pricing model ever changing.