Gas and Gas Price in Solidity

Gas is the unit that measures computational effort on the Ethereum network. Every operation your smart contract performs costs gas, and gas costs real money paid in ETH. If your contract is inefficient, it becomes expensive for users to interact with. During periods of network congestion, the same transaction can cost 10x more than during quiet periods.

This post explains how gas works, how to set gas limits correctly, and how to cut storage costs using variable packing.

What is Gas and How is Cost Calculated

Every time a user calls a function or deploys a contract, the EVM executes your code across thousands of nodes. Those nodes need compensation for their work. Gas is how that compensation is measured and charged.

The formula is simple:

Transaction Cost = Gas Used x Gas Price

Gas price is measured in gwei. One gwei equals 0.000000001 ETH. During peak network usage, gas prices can swing from 20 gwei to 200 gwei or higher. The same operation that costs $2 at 20 gwei can cost $20 at 200 gwei.

Not all operations cost the same amount of gas. Here is a rough breakdown of common EVM operations:

Operation	Gas Cost
Basic arithmetic	3 gas
Reading from storage (cold)	2100 gas
Writing to storage (new value)	20000 gas
Writing to storage (update)	5000 gas
Event emission	~375 gas per topic

Storage operations are by far the most expensive. Designing your contract to minimize storage reads and writes is the single most impactful optimization you can make.

How Gas Limits Work

The gas limit is the maximum gas you are willing to spend on a transaction. It exists to protect you from runaway execution. Without a limit, a bug causing an infinite loop would drain your wallet completely.

There are two kinds of gas limits you need to understand:

Block gas limit is set by the network's validators. It caps the total gas allowed across all transactions in one block. On Ethereum mainnet this is around 30 million gas. It determines how many transactions can fit in a block.

Transaction gas limit is the value you set when sending a transaction. This is what you control.

Here is exactly what happens when you submit a transaction:

1. You set a gas limit (say, 100000 gas)
2. You set a gas price (say, 50 gwei)
3. Your wallet reserves 100000 x 50 = 5000000 gwei (0.005 ETH)
4. The transaction executes and uses actual gas (say, 65000)
5. You pay for 65000 x 50 = 3250000 gwei (0.00325 ETH)
6. The remaining 35000 gas is refunded

The important thing to understand: if your transaction runs out of gas before completing, the EVM reverts all state changes but you do not get the gas back. You pay for the work done up to the point of failure.

 1contract GasLimitDemo {
 2    uint[] public numbers;
 3
 4    // Gas cost grows with each iteration
 5    // Calling addNumbers(1000) needs far more gas than addNumbers(10)
 6    function addNumbers(uint count) public {
 7        for (uint i = 0; i < count; i++) {
 8            numbers.push(i);
 9        }
10    }
11}

If you call addNumbers(1000) with a gas limit of 100000 but the function needs 500000 gas, the transaction fails at the limit, all changes revert, and you pay for the gas consumed up to 100000.

Failed transactions still cost gas. Setting the gas limit too low does not save money. It wastes money on failed attempts while leaving state unchanged.

Setting the Right Gas Limit

Most wallets estimate gas automatically, but their estimates can be wrong for complex or loop-heavy functions. You can add a safety buffer in your scripts:

1// Estimate gas then add 20% buffer
2const gasEstimate = await contract.riskyOperation.estimateGas(100);
3const safeLimit = Math.floor(gasEstimate * 1.2);

A 10-20% buffer is standard practice. For functions with variable loop counts, test with realistic inputs before deploying.

Avoiding Unbounded Loops

The most common cause of out-of-gas failures is iterating over an array whose size can grow without bound.

 1contract BadPattern {
 2    address[] public users;
 3
 4    // DANGEROUS: gas cost is unknown and grows over time
 5    function processAll() public {
 6        for (uint i = 0; i < users.length; i++) {
 7            // process each user
 8        }
 9    }
10}

 1contract GoodPattern {
 2    address[] public users;
 3
 4    // SAFE: caller controls the batch size
 5    function processBatch(uint start, uint end) public {
 6        require(end <= users.length, "Out of bounds");
 7        require(end - start <= 100, "Batch too large");
 8
 9        for (uint i = start; i < end; i++) {
10            // process user
11        }
12    }
13}

The batch pattern lets you process large arrays across multiple transactions without hitting the block gas limit.

Checking Remaining Gas at Runtime

For complex operations, you can read remaining gas mid-execution and bail out early if you are running low:

 1contract GasAware {
 2    function complexOperation() public {
 3        require(gasleft() > 100000, "Not enough gas provided");
 4
 5        // perform expensive work
 6
 7        if (gasleft() < 50000) {
 8            revert("Insufficient gas to complete safely");
 9        }
10    }
11}

Use gasleft() sparingly. It is useful for guard rails in loops or multi-step operations, but it adds complexity.

Variable Packing for Storage Optimization

Storage is the most expensive part of a Solidity contract. Variable packing is a technique that reduces the number of storage slots your contract uses, which directly reduces gas costs.

How EVM Storage Works

The EVM stores state variables in 32-byte (256-bit) slots. Reading or writing a slot costs the same amount of gas whether you use 1 byte or all 32 bytes. If you declare your variables carelessly, you can waste entire slots on variables that only need a few bytes.

Consider this unpacked layout:

 1contract UnpackedStorage {
 2    uint8 a;    // Slot 0: uses 1 byte, 31 bytes wasted
 3    uint256 b;  // Slot 1: full 32 bytes
 4    uint8 c;    // Slot 2: uses 1 byte, 31 bytes wasted
 5    uint256 d;  // Slot 3: full 32 bytes
 6    uint8 e;    // Slot 4: uses 1 byte, 31 bytes wasted
 7}
 8// 5 storage slots = 5 x 20000 = 100000 gas to initialize

Now the same data, packed:

 1contract PackedStorage {
 2    uint8 a;    // Slot 0, byte 0
 3    uint8 c;    // Slot 0, byte 1
 4    uint8 e;    // Slot 0, byte 2
 5    uint256 b;  // Slot 1: full 32 bytes
 6    uint256 d;  // Slot 2: full 32 bytes
 7}
 8// 3 storage slots = 3 x 20000 = 60000 gas to initialize
 9// Saves 40000 gas (40% reduction)

The EVM packs variables into the same slot automatically, but only if they are declared sequentially and fit together. Declaration order matters.

Common Variable Sizes

Type	Size
bool	1 byte
uint8	1 byte
uint16	2 bytes
uint32	4 bytes
uint64	8 bytes
uint128	16 bytes
uint256	32 bytes
address	20 bytes
bytes32	32 bytes

Practical Examples

Token contract storage layout:

1// BAD: 4 storage slots = 80000 gas
2contract TokenBad {
3    address owner;       // Slot 0: 20 bytes + 12 bytes wasted
4    uint256 totalSupply; // Slot 1: 32 bytes
5    bool paused;         // Slot 2: 1 byte + 31 bytes wasted
6    uint256 lastUpdate;  // Slot 3: 32 bytes
7}

 1// GOOD: 3 storage slots = 60000 gas
 2contract TokenGood {
 3    address owner;       // Slot 0: 20 bytes
 4    bool paused;         // Slot 0: 1 byte (packed with owner)
 5    uint256 totalSupply; // Slot 1: 32 bytes
 6    uint256 lastUpdate;  // Slot 2: 32 bytes
 7}
 8// Saves 20000 gas per deployment

User profile with many small fields:

 1// BAD: 7 slots = 140000 gas
 2contract UserProfileBad {
 3    uint256 userId;    // Slot 0
 4    uint8 age;         // Slot 1
 5    bool isActive;     // Slot 2
 6    uint16 reputation; // Slot 3
 7    address wallet;    // Slot 4
 8    uint32 joinDate;   // Slot 5
 9    bool isPremium;    // Slot 6
10}
11
12// GOOD: 3 slots = 60000 gas
13contract UserProfileGood {
14    uint256 userId;    // Slot 0: 32 bytes
15
16    // Slot 1: 20 + 4 + 2 + 1 + 1 + 1 = 29 bytes (fits in 32)
17    address wallet;    // Slot 1: 20 bytes
18    uint32 joinDate;   // Slot 1: 4 bytes
19    uint16 reputation; // Slot 1: 2 bytes
20    uint8 age;         // Slot 1: 1 byte
21    bool isActive;     // Slot 1: 1 byte
22    bool isPremium;    // Slot 1: 1 byte
23}
24// Saves 80000 gas per user (57% reduction)

Packing Rules for Structs and Mappings

Structs follow the same packing rules as contract-level variables:

 1struct BadStruct {
 2    uint8 a;    // Slot 0
 3    uint256 b;  // Slot 1 (breaks packing)
 4    uint8 c;    // Slot 2
 5}
 6
 7struct GoodStruct {
 8    uint8 a;    // Slot 0
 9    uint8 c;    // Slot 0 (packed)
10    uint256 b;  // Slot 1
11}

Mappings and dynamic arrays always start a new storage slot and cannot be packed with adjacent variables:

1contract MappingLayout {
2    uint128 a;                   // Slot 0, first 16 bytes
3    uint128 b;                   // Slot 0, last 16 bytes
4    mapping(address => uint) c;  // Slot 1 (always starts new slot)
5    uint128 d;                   // Slot 2 (cannot pack with mapping)
6}

Real-World Example: NFT Struct

Here is how packing applies to a token struct in an NFT contract:

 1// BEFORE: 8 slots per token = 160000 gas
 2struct Token {
 3    uint256 tokenId;   // Slot 0
 4    address owner;     // Slot 1
 5    address approved;  // Slot 2
 6    uint256 price;     // Slot 3
 7    bool isListed;     // Slot 4
 8    uint8 rarity;      // Slot 5
 9    uint32 mintedAt;   // Slot 6
10    uint16 generation; // Slot 7
11}

 1// AFTER: 4 slots per token = 80000 gas
 2struct Token {
 3    uint256 tokenId;   // Slot 0: 32 bytes
 4    uint256 price;     // Slot 1: 32 bytes
 5
 6    // Slot 2: 20 + 4 + 2 + 1 + 1 = 28 bytes
 7    address owner;     // Slot 2: 20 bytes
 8    uint32 mintedAt;   // Slot 2: 4 bytes
 9    uint16 generation; // Slot 2: 2 bytes
10    uint8 rarity;      // Slot 2: 1 byte
11    bool isListed;     // Slot 2: 1 byte
12
13    address approved;  // Slot 3: 20 bytes
14}
15// Saves 80000 gas per token (50% reduction)
16// For 10000 NFTs: 800 million gas saved in total

The Tradeoff: Packing Adds Computation

Packing is not free. When you read or write a packed variable, the EVM has to read the full 32-byte slot, extract your variable with bitwise operations, modify it, and write the slot back. This adds a small computation cost.

In practice, packing is almost always worth it because storage operations are so much more expensive than arithmetic. Here is a concrete comparison:

 1contract PackedUpdate {
 2    uint128 a;
 3    uint128 b;
 4
 5    function updateBoth(uint128 newA, uint128 newB) public {
 6        a = newA; // First write to slot 0: 20000 gas
 7        b = newB; // Second write to same slot (warm): 5000 gas
 8        // Total: 25000 gas
 9    }
10}

 1contract UnpackedUpdate {
 2    uint256 a;
 3    uint256 b;
 4
 5    function updateBoth(uint256 newA, uint256 newB) public {
 6        a = newA; // Write to slot 0: 20000 gas
 7        b = newB; // Write to slot 1: 20000 gas
 8        // Total: 40000 gas
 9    }
10}

The packed version saves 15000 gas even accounting for the extra computation. The exception is when two packed variables are always read or written independently and rarely together. In that case, packing may add overhead without benefit. Measure before assuming.

Other Optimization Techniques

Cache Storage Reads in Memory

Every time you read a storage variable, it costs 2100 gas (cold) or 100 gas (warm). If you read the same variable multiple times in a function, cache it in a local memory variable first.

 1function transfer(address to, uint256 amount) public {
 2    // Cache the balance once instead of reading storage twice
 3    uint256 senderBalance = balances[msg.sender];
 4    require(senderBalance >= amount, "Insufficient balance");
 5
 6    balances[msg.sender] = senderBalance - amount;
 7    balances[to] += amount;
 8}

Use Events for Data You Do Not Need On-Chain

If you need to record something for off-chain use but never read it inside the contract, use events. They cost roughly 375 gas per indexed topic, far cheaper than a storage write.

1event Transfer(address indexed from, address indexed to, uint256 amount);
2
3function transfer(address to, uint256 amount) public {
4    // state changes here
5    emit Transfer(msg.sender, to, amount); // ~1500 gas total
6}

Storage Refunds

Setting a storage slot to zero gives you a gas refund of 15000 gas. This makes cleanup functions cheaper to run.

1function close() public {
2    delete balances[msg.sender]; // Refunds 15000 gas
3}

Refunds are capped at 20% of total gas used for the transaction, so you cannot refund more than you spent.

Putting It Together: An Optimized Token Contract

This example combines the techniques covered above into a working token contract:

 1contract OptimizedToken {
 2    // Dynamic strings take their own slots
 3    string public name;
 4    string public symbol;
 5
 6    uint256 public totalSupply;
 7
 8    // Slot: 20 + 1 + 1 = 22 bytes, packed together
 9    address public owner;
10    bool public paused;
11    uint8 public decimals;
12
13    mapping(address => uint256) private balances;
14
15    event Transfer(address indexed from, address indexed to, uint256 amount);
16
17    function transfer(address to, uint256 amount) public {
18        require(!paused, "Contract is paused");
19
20        // Read storage once, use local variable for checks
21        uint256 senderBalance = balances[msg.sender];
22        require(senderBalance >= amount, "Insufficient balance");
23
24        balances[msg.sender] = senderBalance - amount;
25        balances[to] += amount;
26
27        emit Transfer(msg.sender, to, amount);
28    }
29}

The contract packs owner, paused, and decimals into one slot, caches the sender balance to avoid a redundant storage read, and uses an event for the transfer log instead of extra storage.

Summary

Gas optimization is not premature optimization. In Ethereum, every byte you waste costs your users real money. The two techniques covered here give you the most leverage:

Gas limits protect you from runaway transactions. Always add a 10-20% buffer on top of estimated gas. Never write unbounded loops. Use batching when you need to process large arrays.

Variable packing cuts storage costs by filling each 32-byte slot fully. Declare small types together, group related fields in structs, and remember that mappings always start a new slot. For a large NFT collection or a frequently-updated contract, the savings compound quickly.

Start with packing your storage layout before deployment. It costs nothing at that stage and the savings are permanent.