Skip to main content
Sui’s gas mechanism is designed to be predictable and fair, with separate accounting for computation and storage costs. Understanding gas helps you optimize your applications and provide better user experiences.

Gas Components

Sui gas has three main components:

Computation Cost

Cost of executing Move bytecode instructions

Storage Cost

Cost of storing new or modified object data

Storage Rebate

Refund for deleting or modifying objects

Total Gas Calculation

The total gas charged to a user is:
The non_refundable_storage_fee is deducted from the storage rebate before it’s returned to the user. This fee goes to the storage fund to ensure long-term sustainability.

Gas Pricing

Reference Gas Price (RGP)

Sui uses a reference gas price set by validators:

Gas Price Rules

Transaction gas price must be >= reference gas price:
Transactions with gas price below RGP will be rejected.

Computation Costs

Computation gas is charged based on:

Instructions Executed

Each Move bytecode instruction has a cost

Storage Operations

Reading and writing objects costs gas

Package Operations

Publishing and upgrading packages

Native Functions

Cryptographic operations and system calls

Typical Gas Costs

From the source code:
These constants are used for testing and give rough estimates. Actual gas costs vary based on execution details and are computed dynamically.

Storage Costs

Storage costs are based on object size:

How Storage Charges Work

1

Object Creation

When creating an object:
  • Calculate: size_bytes * storage_price_per_byte
  • Charge this amount from the gas budget
  • Store as rebate in the object
2

Object Modification

When modifying an object:
  • Release old version’s storage rebate
  • Charge new version’s storage cost
  • Net cost = new_cost - old_rebate
3

Object Deletion

When deleting an object:
  • Full storage rebate minus non-refundable fee
  • Refund goes back to transaction sender

Storage Fund

The storage fund manages long-term storage sustainability:

Gas Budget

Every transaction must specify a gas budget:

Budget Guidelines

Set Appropriately

High enough to complete but not wastefully high

Unused Budget Refunded

Only actual gas used is charged

Must Have Sufficient SUI

Gas coins must cover full budget

Failed TXs Charge Gas

Gas charged even if transaction fails
If your transaction runs out of gas during execution, it will fail and you’ll still be charged for the gas used up to that point.

Gas Optimization Strategies

1. Minimize Storage

2. Batch Operations

3. Use Efficient Data Structures

4. Delete Unused Objects

Checking Gas Costs

Dry Run

Inspect Transaction Effects

Special Cases

Unmetered Gas

Some system operations run without gas metering:
This is used for:
  • Genesis transactions
  • System state updates
  • Validator operations

Coin-Specific Optimizations

Coins have optimized storage access:
This allows Sui to update coin balances without full deserialization, saving gas.

Best Practices

Use dry run to estimate and add 20-30% buffer:
Track actual gas usage to identify optimization opportunities:
  • Store large data off-chain (IPFS, Arweave)
  • Use dynamic fields for optional data
  • Delete temporary objects
  • Minimize object size
For better UX, sponsor gas for users:

Transaction Lifecycle

Understand transaction execution

Sponsored Transactions

Enable gasless transactions

Storage Fund

Learn about storage economics