VERI supply is fixed at 100,000,000

Total supply, maximum supply and the sum of every balance that can ever exist are the same number for VERI: 100,000,000 tokens. Some token listings show the maximum supply as unknown or unlimited. The contract says otherwise, and the sections below show where.

Where the number is set#

The verified source declares the supply as a state variable and hands all of it to the deployer in the constructor:

uint public totalSupply = 100000000 ether;  // total supply of 100 Million Tokens

function VeritaseumToken() {
    balances[msg.sender] = totalSupply;
}

100000000 ether is Solidity for 100,000,000 × 10^18, which is 100000000000000000000000000 base units, or 0x52b7d2dcc80cd2e4000000 in hex. The token has 18 decimals, so that is exactly 100,000,000 VERI. The constructor ran once, in the creation transaction of 23 Apr 2017, and no later code path writes totalSupply.

No mint, burn or pause#

The contract’s state-changing functions are transfer, transferFrom, approve and transferOwnership, and that is the complete list (see the function table). None of them touches totalSupply. There is no function that creates tokens, none that destroys them, and none that stops transfers. Because the contract is not upgradeable, no such function can be added.

What still counts in the supply#

totalSupply never goes down, even when tokens become unreachable:

• Tokens sent to the zero address. transfer and transferFrom have no zero-address check, so VERI can be sent to 0x0. It stays in balances[0x0] and in totalSupply. The zero address holds a non-zero VERI balance today; the second command below reads it.
• Balances overwritten by transferOwnership. That function copies the owner’s balance onto the new owner instead of adding to it, so any VERI the new owner already held is destroyed without totalSupply changing. It has been called once, from a fresh address, so nothing was lost in practice. The details are in How VERI differs from a modern ERC-20.

So the sum of all balances can be smaller than totalSupply, but totalSupply itself is a constant.

Two declarations, one getter#

totalSupply is declared twice in the source: once in the abstract ERC20 contract, which nothing ever writes, and once in VeritaseumToken, where it is initialised. The second shadows the first. The getter in the ABI returns the VeritaseumToken value, 10^26, which is what Etherscan’s Read Contract view and the command below return.

Check it yourself#

Each command is an eth_call to a public Ethereum JSON-RPC endpoint.

# totalSupply(): 0x…52b7d2dcc80cd2e4000000 = 100000000000000000000000000 = 100,000,000 × 10^18
curl -s https://ethereum-rpc.publicnode.com -X POST -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x8f3470a7388c05ee4e7af3d01d8c722b0ff52374","data":"0x18160ddd"},"latest"]}'

# balanceOf(0x0): VERI sent to the zero address, still part of totalSupply
curl -s https://ethereum-rpc.publicnode.com -X POST -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x8f3470a7388c05ee4e7af3d01d8c722b0ff52374","data":"0x70a082310000000000000000000000000000000000000000000000000000000000000000"},"latest"]}'

To turn the hex result into tokens, remove the 0x, convert to decimal and divide by 10^18:

python3 -c 'print(int("0x52b7d2dcc80cd2e4000000", 16) // 10**18)'   # 100000000

https://eth.drpc.org answers the same calls if the first endpoint is busy.

With Foundry installed, its cast command runs the same calls and decodes the answers:

export ETH_RPC_URL=https://ethereum-rpc.publicnode.com

# 100000000000000000000000000 [1e26]
cast call 0x8f3470a7388c05ee4e7af3d01d8c722b0ff52374 'totalSupply()(uint256)'

# The same, in whole VERI: 100000000.000000000000000000
cast call 0x8f3470a7388c05ee4e7af3d01d8c722b0ff52374 'totalSupply()' | xargs cast from-wei

# The zero address's balance, in base units
cast call 0x8f3470a7388c05ee4e7af3d01d8c722b0ff52374 'balanceOf(address)(uint256)' $(cast address-zero)