proxmox/token-lists/docs/DEFILLAMA_ANALYSIS.md

DefiLlama Analysis: Token Metadata Patterns

Date: 2026-01-26
Purpose: Analysis of DefiLlama's approach to token metadata and potential integration patterns

---

Overview

DefiLlama uses a different approach than Uniswap Token Lists. They focus on protocol-level data aggregation rather than token list curation. This document analyzes their patterns and identifies potential learnings.

---

DefiLlama Architecture

Key Differences

Aspect	Uniswap Token Lists	DefiLlama Adapters
Purpose	Token metadata curation	Protocol TVL/data aggregation
Data Source	Manual curation + on-chain	On-chain RPC calls + APIs
Format	JSON token lists	TypeScript adapters
Update Frequency	Manual/PR-based	Automated via adapters
Token Metadata	Static (name, symbol, decimals, logo)	Dynamic (TVL, prices, balances)

DefiLlama Adapter Pattern

// Example DefiLlama adapter structure
async function tvl(timestamp: number, block: number) {
  // Fetch protocol data
  const balances = await getBalances();
  
  // Return token breakdown
  return {
    'ethereum:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48': balance1, // USDC
    'ethereum:0xdAC17F958D2ee523a2206206994597C13D831ec7': balance2, // USDT
  };
}

Key Characteristics:

• ✅ Automated data fetching
• ✅ On-chain verification
• ✅ Multi-chain support
• ✅ Historical data tracking
• ❌ Not token list format
• ❌ No static metadata curation

---

Potential Integration Patterns

1. Automated Token Discovery

DefiLlama Pattern:

• Adapters automatically discover tokens from protocol contracts
• No manual token list maintenance

Application to Token Lists:

• Could create an adapter that:
  • Scans chain for ERC-20 tokens
  • Fetches metadata (name, symbol, decimals)
  • Generates token list automatically
  • Validates against on-chain data

Example Concept:

// Hypothetical auto-discovery script
async function discoverTokens(chainId) {
  const tokens = [];
  
  // Scan for token contracts
  const tokenContracts = await scanForERC20(chainId);
  
  for (const contract of tokenContracts) {
    const metadata = await fetchTokenMetadata(contract);
    tokens.push({
      chainId,
      address: contract,
      name: metadata.name,
      symbol: metadata.symbol,
      decimals: metadata.decimals,
    });
  }
  
  return { tokens };
}

2. On-Chain Verification

DefiLlama Pattern:

• All data verified via RPC calls
• No trust in external APIs

Our Implementation:

• ✅ Already implemented in verify-on-chain.js
• ✅ Validates decimals, symbol, name
• ✅ Supports ERC-20 and Oracle contracts

Enhancement Opportunity:

• Could add automated verification in CI/CD
• Could verify all tokens on each release

3. Multi-Chain Support

DefiLlama Pattern:

• Single adapter supports multiple chains
• Chain-specific RPC endpoints

Our Implementation:

• Currently focused on ChainID 138
• Could extend to support multiple chains
• Could use DefiLlama's chain naming convention

4. Historical Data Tracking

DefiLlama Pattern:

• Adapters support historical timestamps
• Can query data at any point in time

Application to Token Lists:

• Could track token list versions over time
• Could maintain changelog with timestamps
• Could support historical token list queries

---

DefiLlama Repositories Analysis

1. DefiLlama-Adapters

• Purpose: Protocol TVL adapters
• Relevance: Low (different use case)
• Learning: Adapter pattern for automation

2. chainlist

• Purpose: Chain metadata (similar to Chainlist.org)
• Relevance: Medium (chain config, not tokens)
• Learning: Chain configuration patterns

3. icons

• Purpose: Token/chain icons
• Relevance: High (logo management)
• Learning: Centralized logo hosting

4. defillama-server

• Purpose: Backend API server
• Relevance: Low (internal infrastructure)
• Learning: API design patterns

---

Recommendations

✅ Already Implemented

1. On-Chain Verification ✅

   • Our verify-on-chain.js follows DefiLlama's verification pattern
   • RPC-based validation
   • Multi-endpoint support

2. Automated Validation ✅

   • CI/CD integration
   • Automated checks on PRs
   • Release validation

💡 Potential Enhancements

1. Automated Token Discovery

   • Create adapter-style script to discover tokens
   • Auto-populate token list from on-chain data
   • Validate and merge into curated list

2. Logo Management

   • Consider DefiLlama's centralized icon repository
   • Host logos in dedicated repository
   • Reference from token list

3. Multi-Chain Support

   • Extend token list structure for multiple chains
   • Use chain-specific validation
   • Support chain-specific tags

4. Historical Tracking

   • Maintain version history
   • Support historical queries
   • Track token additions/removals over time

---

Conclusion

DefiLlama's Approach:

• ✅ Excellent for automated data aggregation
• ✅ Strong on-chain verification patterns
• ❌ Not designed for token list curation

Our Approach:

• ✅ Complies with Uniswap Token Lists spec
• ✅ Enhanced validation and security
• ✅ Manual curation for quality control

Key Takeaway: DefiLlama's adapter pattern is excellent for automation and verification, but token lists require curation and quality control that Uniswap's specification provides. Our implementation combines the best of both:

• Uniswap's specification for compatibility
• DefiLlama-style verification for accuracy
• Enhanced validation for security

---

Last Updated: 2026-01-26