uint and uint256 in Solidity: The Default Number Type

Every smart contract needs to count something. Tokens, votes, IDs, prices, timestamps. The number type Solidity reaches for first is uint256. You will see it on almost every line of state in production code, from ERC20 balances to Uniswap pool reserves to governance vote tallies.

uint256 public totalSupply;
uint256 public price = 0.05 ether;
uint256 public deadline;
uint256 public counter;

The keyword uint by itself is an alias for uint256. Most style guides recommend writing the explicit size so a reader does not have to remember the alias. Inside an array or a struct, you may want a smaller variant for packing — see the next section.

The EVM word size is 256 bits. When you declare a uint8 on its own, the compiler still loads a full 32 byte slot and masks the unused bits, so the gas cost is identical to uint256. The only situation where smaller types save real gas is when several of them fit together into the same 32 byte slot:

struct PackedAccount {
    uint128 balance;   // 16 bytes
    uint64  lastSeen;  // 8 bytes
    uint64  nonce;     // 8 bytes
    // 3 fields total in ONE storage slot — saves 40 000 gas per write
}

Outside packing, prefer uint256 everywhere. It is the type the EVM works with natively, the type used by every audited OpenZeppelin contract, and the type that requires zero downcasting when interacting with mappings or events.

Before Solidity 0.8, an addition that exceeded the maximum value of the type silently wrapped around to zero. Subtracting from zero wrapped around to the maximum value. These two bugs caused real exploits — most famously the BeautyChain (BEC) overflow that minted unlimited tokens and crashed the price.

// Solidity 0.8+ default: this REVERTS the transaction
uint256 a = type(uint256).max;
a + 1;          // overflow → revert

uint256 b = 0;
b - 1;          // underflow → revert

// You can opt out when you have proven it is safe
unchecked {
    for (uint256 i = 0; i < array.length; i++) {
        // no overflow check on i++ — saves ~30 gas per loop
    }
}

The unchecked block is a deliberate optimisation, not a default. Use it only for loop counters, math you have proven cannot overflow, or hot paths where you have audit coverage. Leaving math checked is the safest default.

// 1. ERC20 balance tracking
mapping(address => uint256) public balanceOf;

// 2. ERC721 token IDs
mapping(uint256 => address) public ownerOf;

// 3. Auction bid amounts
uint256 public highestBid;

// 4. Voting weights
mapping(address => uint256) public votingPower;

// 5. Time-locked withdrawals
uint256 public unlockAt = block.timestamp + 7 days;

// 6. Loop iteration
for (uint256 i = 0; i < winners.length; i++) {
    payable(winners[i]).transfer(reward);
}

Every one of those examples is non-negative by definition. A balance cannot be minus ten tokens, an NFT cannot be token minus three, and a deadline cannot be set in negative time. Whenever the value is a count or an amount, reach for uint. If you genuinely need negatives — a profit-and-loss delta, a temperature, a balance difference — the right type is int.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract DepositCounter {
    uint256 public totalDeposits;
    uint256 public depositCount;
    mapping(address => uint256) public depositsByUser;

    event Deposited(address indexed user, uint256 amount, uint256 newTotal);

    function deposit() external payable {
        require(msg.value > 0, "zero deposit");

        depositsByUser[msg.sender] += msg.value;
        totalDeposits              += msg.value;

        unchecked {
            depositCount += 1; // safe — would take 10^77 deposits to overflow
        }

        emit Deposited(msg.sender, msg.value, totalDeposits);
    }
}

Three uses of uint256 in 20 lines: a running total, an individual user balance inside a mapping, and a counter that opts into unchecked because we can prove it will never wrap. This pattern shows up in every vault, staking contract, and DeFi pool you will read.

The full picture lives in the Solidity smart contracts beginner guide. The signed cousin is covered in int and int256 in Solidity. When you store many uints together, see arrays in Solidity or mappings in Solidity. To bundle a uint with other fields, read structs in Solidity.