Token Contract

The totalSupply function returns the total number of tokens in existence. Minting is the process of creating new tokens, typically controlled by a privileged address (e.g., the contract owner or a minter role). This is a critical governance mechanism, as uncontrolled minting can lead to inflation and devalue the token.

• ERC-20 Example: function totalSupply() external view returns (uint256);
• Fixed Supply: Many tokens have a hard-coded maximum supply (e.g., 21 million BTC, 1 billion tokens).
• Dynamic Supply: Some contracts allow for future minting based on governance votes or algorithmic rules.

The balanceOf function queries the token balance of a specific address. The transfer and transferFrom functions are the core mechanics for moving tokens between accounts. These functions must update internal balance mappings and emit standardized Transfer events for blockchain explorers and indexers.

• Key Functions: balanceOf(address), transfer(address to, uint256 amount), transferFrom(address from, address to, uint256 amount).
• Events: event Transfer(address indexed from, address indexed to, uint256 value);
• Gas Efficiency: Optimized balance storage (like using uint96) can reduce gas costs for users.

A security feature that allows a token owner to approve a third-party address (like a decentralized exchange) to spend a specific amount of tokens on their behalf. The allowance function checks the approved amount. This enables complex interactions like trading, lending, and staking without transferring custody.

• Function: approve(address spender, uint256 amount) grants an allowance.
• Function: allowance(address owner, address spender) checks the allowance.
• Use Case: To swap tokens on Uniswap, you first approve the Uniswap router contract to spend your tokens.

Standardized functions that return descriptive information about the token. For fungible tokens (ERC-20), this includes name, symbol, and decimals. For non-fungible tokens (ERC-721/ERC-1155), the tokenURI function points to a JSON file containing the asset's name, image, and attributes, often stored on IPFS or Arweave.

• ERC-20: name(), symbol(), decimals().
• ERC-721: tokenURI(uint256 tokenId) returns a URL to off-chain metadata.
• Importance: This data is essential for wallets, marketplaces, and explorers to display the token correctly.

Many token contracts implement access control mechanisms to restrict sensitive functions (like minting, pausing, or upgrading) to authorized addresses. This is often managed via the Ownable pattern (a single owner) or more granular role-based systems using libraries like OpenZeppelin's AccessControl.

• Ownable: owner() returns the contract owner; onlyOwner modifier restricts functions.
• Roles: Common roles include MINTER_ROLE, PAUSER_ROLE, and DEFAULT_ADMIN_ROLE.
• Security: Proper access control is critical to prevent unauthorized minting or contract takeover.

Token contracts emit standardized events to log significant state changes on the blockchain. These events are not executed but are cheap to store and are essential for off-chain applications (like front-ends and indexers) to track token movements and approvals efficiently.

• Core Events: Transfer, Approval (ERC-20), ApprovalForAll (ERC-721).
• Indexed Parameters: Key parameters (like from and to addresses) are marked as indexed for efficient filtering.
• Utility: Wallets like MetaMask and block explorers like Etherscan use these events to display transaction history.

Wrapped tokens are ERC-20 tokens that represent a native asset from another blockchain, locked in a custodian contract (e.g., a bridge).

• Mechanism: 1:1 pegged representation (e.g., 1 WBTC = 1 Bitcoin).
• Purpose: Allows non-EVM native assets like BTC or ETH to be used within DeFi protocols on Ethereum.
• Examples: WETH (wrapped ETH), WBTC (wrapped Bitcoin), wstETH (wrapped staked ETH).

The most common application, creating interchangeable tokens like stablecoins (USDC, DAI) and governance tokens (UNI, AAVE). These contracts manage:

• Total supply and individual balances.
• Functions to transfer and approve spending.
• Standard interfaces for wallets and exchanges to integrate. They form the backbone of DeFi liquidity pools, lending markets, and payment systems.

Token contracts that mint unique, indivisible assets with distinct metadata. Key uses include:

• Digital Art & Collectibles: Verifying provenance and ownership on platforms like OpenSea.
• In-Game Assets: Representing unique items, characters, or land parcels.
• Real-World Asset (RWA) Tokenization: Digitizing ownership of physical assets like real estate. Each token has a unique ID and is non-interchangeable with another.

Token contracts encode voting power, enabling decentralized autonomous organizations (DAOs). Holders use these tokens to:

• Propose and vote on protocol upgrades, treasury spending, or parameter changes.
• Delegate voting rights to representatives.
• Signal sentiment through mechanisms like snapshot voting (off-chain) or on-chain execution. Examples include Compound's COMP and MakerDAO's MKR tokens.

Contracts can gate functionality or services behind token ownership. This includes:

• Payments & Fees: Using a native token to pay for transaction fees (e.g., ETH for gas, AVAX for subnet fees).
• Software Licensing: Granting access to an API or premium feature.
• Membership & Subscriptions: NFTs or tokens that act as keys to exclusive communities, content, or events.

Token contracts facilitate proof-of-stake consensus and DeFi yield strategies. Functions include:

• Native Staking: Locking tokens (e.g., ETH, SOL) to secure the network and earn rewards.
• Liquid Staking: Minting a derivative token (e.g., stETH, mSOL) representing staked assets.
• Yield-Bearing Vaults: Depositing tokens into a contract that automatically farms yield from lending or liquidity provision.

Contracts that represent assets native to another blockchain, enabled by bridge protocols. These wrapped tokens (e.g., WETH, WBTC) are crucial for interoperability. The contract:

• Mints a token on the destination chain when assets are locked on the source chain.
• Burns the token to redeem the original asset.
• Manages the custody model, which can be centralized (custodial bridge) or decentralized (via a mint/burn module).

Many token contracts have privileged functions (e.g., mint, pause, upgrade) controlled by an owner or admin address. A compromised private key or flawed access logic can lead to:

• Unauthorized minting of new tokens, causing inflation.
• Permanent locking of all user funds via a pause function.
• A malicious contract upgrade draining all assets. Best Practice: Use multi-signature wallets or timelocks for sensitive operations.

A classic vulnerability where arithmetic operations exceed the maximum (overflow) or minimum (underflow) value a variable can hold. In early ERC-20 contracts, this could allow an attacker to create an enormous balance from nothing.

• Example: balance -= amount could underflow if amount > balance. Mitigation: Use SafeMath libraries (now integrated into Solidity >=0.8.0) which automatically revert on overflow/underflow.

The ERC-20 approve function grants a spender an allowance to transfer tokens on your behalf. Risks include:

• Race Conditions: If you change an allowance from 5 to 10, a pending transaction could still spend the original 5, then the new 10.
• Unlimited Approvals: Granting an infinite allowance (type(uint256).max) to a malicious or buggy contract exposes all tokens in that wallet. Best Practice: Use increaseAllowance/decreaseAllowance functions and revoke unused approvals.

An attacker's malicious contract calls back into the vulnerable token contract before the initial function call completes, manipulating state. Famous in the DAO hack.

• Can drain funds from contracts that perform external calls before updating internal balances. Mitigation: Use the Checks-Effects-Interactions pattern (update state before calling external addresses) or employ reentrancy guards.

Many tokens rely on proxy patterns for upgradeability, storing logic in a separate contract. Risks include:

• Proxy Admin Risk: A single entity controls the upgrade, potentially deploying malicious logic.
• Storage Collision: Incorrect upgradeable contract design can corrupt data storage.
• Lack of Transparency: Users may not be aware they are interacting with a mutable contract. Due Diligence: Verify if a contract is upgradeable and who controls the proxy admin.

Tokens with low liquidity or unique supply mechanics are vulnerable to flash loan-enabled market manipulation. An attacker can:

• Borrow massive capital to temporarily dominate a token's liquidity pool.
• Manipulate oracle prices or governance votes that rely on token balance snapshots.
• Exploit lending protocols that use the manipulated price for collateral valuation. This highlights risks beyond the contract's code, stemming from its economic design.

Minting is the process of creating new token supply, typically controlled by privileged functions within the token contract (e.g., mint). Burning is the irreversible destruction of tokens, removing them from circulation, often via a burn function. These mechanisms are critical for:

• Managing inflation/deflation
• Distributing rewards
• Implementing tokenomics (e.g., buyback-and-burn)
• Correcting errors in token distribution

An approval is a transaction where a token holder authorizes another address (like a DEX or lending protocol) to spend a specific amount of their tokens. The approved amount is recorded as an allowance in the token contract's state. This delegation is essential for DeFi composability, enabling actions like swapping on Uniswap or depositing as collateral on Aave without transferring custody to the protocol first.

Poorly implemented token contracts can contain critical security flaws. Key vulnerabilities include:

• Incorrect ERC-20 implementations: Missing return values or flawed event emissions.
• Overflow/Underflow bugs: Historically allowed by Solidity <0.8; mitigated by SafeMath or compiler checks.
• Centralization risks: Unlimited minting capability held by a single private key.
• Flash loan attack vectors: Manipulation of price oracles due to low liquidity. Audits by reputable firms are essential before deployment.