How NEAR fees work: gas vs storage
How NEAR fees work: gas (measured in Tgas) pays for compute and is burnt, while storage staking locks NEAR per byte and is released when data is deleted.
Beginner4 min read3-question check
Every NEAR contract pays two different costs, and most optimisation advice only makes sense once you keep them apart. Gas pays for computation: it is bought by the signer of a transaction and burnt as the code runs. Storage staking pays for bytes kept on-chain: it is not a fee at all but a slice of the account balance that stays locked while the data exists.
Cutting one does not cut the other. A method can be cheap in gas and still lock a lot of NEAR because it writes a big record; a method that writes nothing can still burn a lot of gas looping over data.
Gas: paying for compute#
- Gas is a unit of compute. 1 Tgas = 10¹² gas, roughly 1 ms of execution time.
- The signer pays. The transaction buys its attached (prepaid) gas up front at the current gas price; the fee is
gas burnt × gas price. - Unused gas is refunded to the signer. Attaching more gas than needed costs nothing extra, it only raises the ceiling.
- The gas price is set by the protocol, not by an auction: it moves by at most 1% per block depending on how full blocks are, and never drops below a floor. It has long sat at that floor, about 0.0001 NEAR per Tgas.
- Prepaid gas per transaction is capped by the protocol parameter
max_total_prepaid_gas. Older docs say 300 Tgas; mainnet’s protocol config (EXPERIMENTAL_protocol_configRPC) reports 1 PGas (1,000 Tgas) at protocol version 86.
| Gas | Storage staking | |
|---|---|---|
| Pays for | Computation, receipts, I/O | Bytes stored in an account (state and contract code) |
| Unit | gas (1 Tgas = 10¹² gas) | bytes (10¹⁹ yoctoNEAR each) |
| Who pays | The transaction signer | The account that holds the data, from its own balance |
| Spent or locked? | Burnt (spent) | Locked, not spent |
| Getting it back | Only the unused part of prepaid gas | Released when the bytes are deleted |
Storage staking: a locked balance#
Each byte an account stores requires 10¹⁹ yoctoNEAR of its balance to stay locked, which is 1 NEAR per 100 KB. That covers contract state (every key and value your collections write) and the contract’s Wasm code itself.
Locked is the key word. When the contract deletes data, the matching NEAR becomes available again on the same account. If a call would grow the state beyond what the balance can cover, the receipt fails with a LackBalanceForState error and its changes are rolled back.
Check yourself
3 questions · progress saved in this browser