The Importance of Token Standards:

1. Interoperability:
   - Any wallet can display any standard token
   - Exchanges can list tokens easily
   - dApps can integrate tokens seamlessly

2. Security:
   - Standards are battle-tested
   - Common patterns reduce bugs
   - Auditors know what to check

3. Composability:
   - Tokens work together
   - DeFi protocols can interact
   - Ecosystem effects are powerful

4. User Experience:
   - Consistent interface
   - Predictable behavior
   - Reduced learning curve

Fungible Token Properties:

1. Identical Value:
   - Token A = Token B
   - Each unit worth the same

2. Divisible:
   - Can be split into smaller units
   - Typically 18 decimal places

3. Interchangeable:
   - Any token can replace any other
   - No unique properties

4. Standardized:
   - All tokens follow same rules
   - Can be used anywhere

ERC-20 Core Functions:

1. totalSupply():
   - Returns total number of tokens
   - Immutable (or controlled minting)

2. balanceOf(address):
   - Returns token balance of an address
   - Core accounting function

3. transfer(to, amount):
   - Sends tokens from caller to recipient
   - Most common operation

4. approve(spender, amount):
   - Allows spender to withdraw tokens
   - Creates allowance

5. allowance(owner, spender):
   - Checks remaining allowance
   - Used for delegated spending

6. transferFrom(from, to, amount):
   - Spender moves tokens from owner to recipient
   - Uses allowance system

Events:
- Transfer(from, to, amount): Emitted when tokens move
- Approval(owner, spender, amount): Emitted when allowance changes

Token Transfer Flow:

1. User A wants to send 100 tokens to User B
2. User A calls transfer(B, 100)
3. Contract checks: balanceOf(A) >= 100
4. Contract updates: balanceOf(A) = balanceOf(A) - 100
5. Contract updates: balanceOf(B) = balanceOf(B) + 100
6. Contract emits Transfer(A, B, 100)
7. Transaction completes

Token Approval Flow:

1. User A wants to allow DEX to spend 1000 tokens
2. User A calls approve(DEX, 1000)
3. Contract sets: allowance[A][DEX] = 1000
4. Contract emits Approval(A, DEX, 1000)
5. DEX can now call transferFrom(A, DEX, 1000)
6. Contract checks: allowance[A][DEX] >= 1000
7. Contract transfers tokens
8. Contract updates: allowance[A][DEX] = 0

Economic Models for Tokens:

1. Governance Token:
   - Voting rights
   - Proposal creation
   - Parameter setting
   - Examples: UNI, AAVE, COMP

2. Utility Token:
   - Pay for services
   - Access to features
   - Discounts on fees
   - Examples: LINK, BAT, GAS

3. Security Token:
   - Represent real assets
   - Equity/debt ownership
   - Regulatory compliant
   - Examples: Regulated tokens

4. Stablecoin:
   - Pegged to value
   - Collateralized
   - Price stability
   - Examples: USDC, DAI, USDT

5. Meme Token:
   - Community driven
   - Viral marketing
   - Speculative value
   - Examples: DOGE, SHIB

Value Accrual Mechanisms:
- Buyback and burn (deflationary pressure)
- Fee sharing (revenue distribution)
- Staking rewards (yield generation)
- Governance rights (decision power)
- Discounts and benefits (utility value)

Common ERC-20 Vulnerabilities:

1. Approval Front-Running:
   - Attacker sees approval transaction
   - Submits transferFrom with higher gas
   - Spends tokens before approval updated
   - Mitigation: Use permit or increase/decrease allowance

2. Transfer Hook Reentrancy:
   - Custom tokens have receive hooks
   - Could re-enter before state updated
   - Mitigation: Use checks-effects-interactions

3. Balance Manipulation:
   - Flash loan attacks
   - Rounding errors
   - Mitigation: Use SafeMath (pre-0.8.0)

4. Allowance Inflation:
   - approve(MAX_UINT256) issues
   - Decrease allowance to MAX_UINT256
   - Mitigation: Increase/decrease allowance functions

Non-Fungible Token Properties:

1. Unique Identity:
   - Each token has unique ID
   - No two tokens are identical

2. Indivisible:
   - Cannot be split
   - 1 NFT = 1 whole unit

3. Provenance:
   - Full transaction history
   - Verifiable ownership

4. Metadata:
   - External data linked
   - Properties stored off-chain

5. Scarcity:
   - Limited supply (often)
   - Controlled minting

Fungible vs Non-Fungible:

Fungible (ERC-20):
Token A = Token B = Token C
All tokens are identical

Non-Fungible (ERC-721):
Token A ≠ Token B ≠ Token C
Each token has unique properties

ERC-721 Core Functions:

View Functions:
1. balanceOf(owner): Returns number of NFTs owned
2. ownerOf(tokenId): Returns owner of specific NFT

Transfer Functions:
3. transferFrom(from, to, tokenId): Basic transfer
4. safeTransferFrom(from, to, tokenId): Safe transfer (checks receiver)

Approval Functions:
5. approve(to, tokenId): Approve single token
6. setApprovalForAll(operator, bool): Approve all tokens
7. getApproved(tokenId): Check single approval
8. isApprovedForAll(owner, operator): Check all approval

Events:
- Transfer(from, to, tokenId): When token moves
- Approval(owner, approved, tokenId): Single approval
- ApprovalForAll(owner, operator, approved): All approval

Extension: ERC-721 Metadata
- tokenURI(tokenId): Returns metadata URI
- name(): Token collection name
- symbol(): Token collection symbol

Extension: ERC-721 Enumerable
- totalSupply(): Total tokens minted
- tokenByIndex(index): Token ID by index
- tokenOfOwnerByIndex(owner, index): Token by owner and index

NFT Transfer Flow:

1. User A owns NFT with Token ID 123
2. User A calls safeTransferFrom(A, B, 123)
3. Contract checks: ownerOf(123) == A
4. Contract updates: ownerOf(123) = B
5. Contract updates: balanceOf(A) = balanceOf(A) - 1
6. Contract updates: balanceOf(B) = balanceOf(B) + 1
7. Contract checks: B supports ERC-721 (if safe transfer)
8. Contract emits Transfer(A, B, 123)

NFT Approval Flow:

1. User A wants to allow DEX to sell NFT 123
2. User A calls approve(DEX, 123)
3. Contract sets: approved[123] = DEX
4. Contract emits Approval(A, DEX, 123)
5. DEX calls transferFrom(A, B, 123)
6. Contract checks: approved[123] == DEX
7. Contract transfers token
8. Contract clears: approved[123] = 0

Metadata Options:

1. On-Chain Metadata:
   - Stored in contract
   - Immutable and verifiable
   - Expensive (gas costs)
   - Used for: Simple data, security-critical

2. Off-Chain Metadata (IPFS):
   - Stored on IPFS
   - Decentralized and permanent
   - Uses content-addressing
   - Used for: Most NFT projects

3. Off-Chain Metadata (Centralized):
   - Stored on server
   - Easy to update
   - Centralized control
   - Used for: Game items (frequent updates)

4. Hybrid Approach:
   - Base data on-chain
   - Extended data off-chain
   - Balances cost and flexibility

Metadata Structure (OpenSea Standard):
{
  "name": "My NFT",
  "description": "This is a unique NFT",
  "image": "ipfs://Qm...",
  "attributes": [
    {"trait_type": "Rarity", "value": "Legendary"},
    {"trait_type": "Level", "value": 99}
  ],
  "properties": {
    "files": [{"uri": "ipfs://Qm...", "type": "image/png"}]
  }
}

Common ERC-721 Vulnerabilities:

1. Reentrancy on Safe Transfer:
   - Safe transfer calls receiver hook
   - Hook could call back into contract
   - Mitigation: Checks-effects-interactions

2. Approval Front-Running:
   - Similar to ERC-20 approval
   - Mitigation: Use setApprovalForAll

3. Token ID Reuse:
   - Burning then re-minting
   - History confusion
   - Mitigation: Never reuse token IDs

4. Metadata Manipulation:
   - Centralized metadata can be changed
   - Mitigation: Use IPFS with content addressing

ERC-1155 - The Best of Both Worlds:

Why ERC-1155 Exists:
1. Single Contract:
   - One contract for multiple token types
   - Reduces deployment costs

2. Batch Transfers:
   - Transfer multiple tokens at once
   - Atomic operations

3. Gas Efficiency:
   - Batch operations save gas
   - Consolidated logic

4. Fungible + Non-Fungible:
   - Support both types
   - Flexible design

5. Hooks:
   - Callback support
   - Advanced functionality

Token ID-Based Types:

Fungible Tokens:
- Token ID represents a class
- amount > 1 for each ID
- Example: Gold (ID 1) = 1000 units

Non-Fungible Tokens:
- Token ID represents specific item
- amount = 1 for each ID
- Example: Sword (ID 101) = 1 unit

Hybrid:
- Some tokens fungible
- Some tokens non-fungible
- Example: Items with quantities

ID Schema Example:
Gold: ID = 1 (fungible, amount 10000)
Silver: ID = 2 (fungible, amount 50000)
Sword: ID = 101 (non-fungible, amount 1)
Shield: ID = 102 (non-fungible, amount 1)

Batch Transfer Flow:

1. User wants to transfer 3 different tokens
2. User calls safeBatchTransferFrom(from, to, ids, amounts)
3. Contract processes:
   - Token 1: ID 1, amount 100
   - Token 2: ID 2, amount 200
   - Token 3: ID 101, amount 1
4. Contract updates all balances atomically
5. Contract calls receiver hooks
6. If any transfer fails, all revert
7. Emits TransferBatch event

Gas Savings:
- Single batch transfer: 10,000 gas
- Three individual transfers: 30,000 gas
- Savings: ~66% gas reduction

balanceOfBatch Flow:

1. User wants balances of multiple tokens
2. User calls balanceOfBatch(accounts, ids)
3. Contract returns array of balances
4. Example:
   accounts = [A, B, C]
   ids = [1, 2, 3]
   returns [10, 20, 30]

Efficiency:
- One call instead of multiple
- Reduces RPC calls
- Better for dApps

Ideal Use Cases:

1. Gaming:
   - Multiple item types in one contract
   - Gold, weapons, armor, potions
   - Batch transfers for inventory

2. Trading Card Games:
   - Cards as NFTs (amount=1)
   - Resources as fungible tokens
   - Batch pack opening

3. Marketplace:
   - Sell multiple items at once
   - Batch approvals
   - Efficient trading

4. Subscription Models:
   - Access tokens
   - Tiered membership
   - Batch minting

5. Event Ticketing:
   - Different seat types
   - Batch transfers
   - Scalable

Unique Security Concerns:

1. Batch Transfer Reentrancy:
   - Multiple hooks called
   - Reentrancy possible
   - Mitigation: ReentrancyGuard

2. Token ID Conflicts:
   - Same ID used for different purposes
   - Mitigation: Clear ID schema

3. Amount > 1 for NFTs:
   - NFTs should have amount 1
   - Check before transfer

4. URI Resolution:
   - Different URIs per token
   - Gas costs for reading

ERC-777 Key Features:

1. Hooks:
   - tokensToSend(): Called before transfer
   - tokensReceived(): Called after transfer
   - Enable advanced logic

2. Operators:
   - Similar to allowance but more powerful
   - Can send/receive on behalf
   - Better than approve/transferFrom

3. Granularity:
   - Minimum transfer amount
   - Prevents dust attacks

4. Backward Compatible:
   - Implements ERC-20 interface
   - Works with existing wallets

5. Events:
   - More detailed logging
   - Better traceability

When to Use ERC-777:
- Need advanced transfer logic
- Want hooks for security
- Need operator functionality
- Want better backward compatibility

ERC-4626 Key Concepts:

1. Asset vs Shares:
   - Asset: Underlying token (e.g., USDC)
   - Shares: Vault representation (e.g., yvUSDC)

2. Conversion:
   - convertToShares(assets): Assets → Shares
   - convertToAssets(shares): Shares → Assets

3. Deposit/Mint:
   - deposit(assets, receiver) → shares
   - mint(shares, receiver) → assets used

4. Withdraw/Redeem:
   - withdraw(assets, receiver, owner) → shares burned
   - redeem(shares, receiver, owner) → assets returned

5. Yield Accrual:
   - Shares increase in value
   - Represent proportional ownership

APY Calculation:
APY = (Shares_Price_End - Shares_Price_Start) / Shares_Price_Start × 365 / Days

Use Cases:
- Yield farming strategies
- Lending pools
- Staking rewards
- Automated yield generation

ERC-3643 Key Features:

1. Identity Module:
   - KYC/AML verification
   - On-chain identity
   - Compliance checks

2. Transfer Restrictions:
   - Only verified addresses can hold
   - Transaction limits
   - Jurisdiction controls

3. Agent Management:
   - Delegated authority
   - Compliance agents
   - Corporate actions

4. Document Management:
   - Attach legal documents
   - Proxy voting
   - Investor reporting

5. Recovery:
   - Lost key recovery
   - Beneficiary designations
   - Corporate actions

Use Cases:
- Security tokens
- Real estate tokenization
- Private equity
- Bonds and debt

Token Security Checklist:

☐ Reentrancy protection
☐ Access control (Ownable/AccessControl)
☐ Overflow protection (SafeMath or 0.8.0+)
☐ Emergency pause (Pausable)
☐ Upgrade path (Transparent proxy)
☐ Multiple audits
☐ Bug bounty program
☐ Test coverage > 95%
☐ Documentation complete
☐ Emergency withdrawal

☐ Checks-effects-interactions
☐ Front-running protection
☐ Rate limiting
☐ Input validation
☐ Event logging
☐ No hardcoded values
☐ Timelocks for sensitive ops
☐ Multi-sig for admin

Distribution Models:

1. Fair Launch:
   - No pre-mine
   - Equal opportunity
   - Community-driven
   - Example: Uniswap (initial)

2. Private Sale:
   - Early investors
   - Discounts for risk
   - Lock-up periods
   - Example: Most projects

3. Public Sale (ICO/IDO):
   - Crowdfunding
   - Democratic participation
   - Regulatory considerations
   - Example: Many projects

4. Airdrop:
   - Free distribution
   - Community building
   - Marketing tool
   - Example: Uniswap UNI

5. Staking Rewards:
   - Lock tokens
   - Earn yield
   - Long-term alignment
   - Example: Curve CRV

6. Liquidity Mining:
   - Provide liquidity
   - Earn governance tokens
   - Bootstrapping
   - Example: Most DeFi protocols

Vesting Schedules:

1. Team Vesting:
   - 1-year cliff
   - 24-48 months linear vesting
   - Aligns long-term interests

2. Investor Vesting:
   - 6-month cliff
   - 12-24 months vesting
   - Reduces sell pressure

3. Community Treasury:
   - Multi-sig controlled
   - Governance approval
   - Operational funding

4. Liquidity Locking:
   - LP tokens locked
   - Prevents rug pulls
   - Builds trust