Add complete token lists for Ethereum Mainnet, ChainID 138, and ALL Mainnet
- Added Ethereum Mainnet token list (1 token: USDT) - Updated ChainID 138 token list (6 tokens: added cUSDT and cUSDC) - Added ALL Mainnet token list (9 tokens including AUSDT) - Discovered ALL Mainnet tokens via Transfer event scanning - Updated validation scripts for multi-chain support - Created comprehensive documentation and guides - Updated master documentation indexes - All token lists validated and ready for submission
This commit is contained in:
defiQUG
212
token-lists/docs/DEFILLAMA_ANALYSIS.md
Normal file
212
token-lists/docs/DEFILLAMA_ANALYSIS.md
Normal file
@@ -0,0 +1,212 @@
|
||||
# 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
|
||||
|
||||
```typescript
|
||||
// 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:**
|
||||
```javascript
|
||||
// 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
|
||||
245
token-lists/docs/UNISWAP_COMPARISON.md
Normal file
245
token-lists/docs/UNISWAP_COMPARISON.md
Normal file
@@ -0,0 +1,245 @@
|
||||
# Comparison: DBIS Token Lists vs Uniswap Token Lists
|
||||
|
||||
**Date**: 2026-01-26
|
||||
**Status**: Updated with @uniswap/token-lists integration
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This document compares our DBIS Chain 138 Token List implementation with the official Uniswap Token Lists specification and package.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Comparison
|
||||
|
||||
### Schema & Validation
|
||||
|
||||
| Feature | Uniswap Package | DBIS Implementation | Status |
|
||||
|---------|----------------|---------------------|--------|
|
||||
| JSON Schema | ✅ Exported from package | ✅ Fetched from URL (now uses package) | ✅ **Integrated** |
|
||||
| TypeScript Types | ✅ `TokenList`, `TokenInfo`, `Version` | ⚠️ Manual validation | ✅ **Available** |
|
||||
| Schema Validation | ✅ Via AJV | ✅ Via AJV with fallback | ✅ **Enhanced** |
|
||||
| EIP-55 Checksum | ❌ Not included | ✅ Custom validation | ✅ **Enhanced** |
|
||||
| Duplicate Detection | ❌ Not included | ✅ Address & symbol checks | ✅ **Enhanced** |
|
||||
| Chain ID Validation | ❌ Not included | ✅ Strict validation (138) | ✅ **Enhanced** |
|
||||
| On-Chain Verification | ❌ Not included | ✅ RPC verification | ✅ **Enhanced** |
|
||||
| Logo Validation | ❌ Not included | ✅ URL accessibility check | ✅ **Enhanced** |
|
||||
|
||||
### Package Integration
|
||||
|
||||
| Feature | Before | After | Status |
|
||||
|---------|--------|-------|--------|
|
||||
| Schema Source | URL fetch | `@uniswap/token-lists` package | ✅ **Integrated** |
|
||||
| Type Safety | Manual | TypeScript types available | ✅ **Available** |
|
||||
| Dependency | None | `@uniswap/token-lists@^1.0.0-beta.34` | ✅ **Added** |
|
||||
| Fallback | None | URL fetch fallback | ✅ **Maintained** |
|
||||
|
||||
---
|
||||
|
||||
## Feature Comparison
|
||||
|
||||
### ✅ What We Have That Uniswap Doesn't
|
||||
|
||||
1. **Enhanced Validation**
|
||||
- EIP-55 checksum validation
|
||||
- Duplicate address detection
|
||||
- Duplicate symbol detection (per chainId)
|
||||
- Strict chain ID validation
|
||||
- Logo URL validation
|
||||
|
||||
2. **On-Chain Verification**
|
||||
- RPC-based contract verification
|
||||
- ERC-20 token verification
|
||||
- Oracle contract verification
|
||||
- Dual RPC endpoint support with fallback
|
||||
|
||||
3. **CI/CD Integration**
|
||||
- GitHub Actions PR validation
|
||||
- Release workflow with full validation
|
||||
- Automated version bumping
|
||||
- minisign signing integration
|
||||
|
||||
4. **Security Features**
|
||||
- minisign signing support
|
||||
- Checksum generation
|
||||
- Public key verification
|
||||
|
||||
5. **Documentation**
|
||||
- Comprehensive integration guide
|
||||
- Token list policy
|
||||
- Authoring guide
|
||||
- Changelog tracking
|
||||
|
||||
### ✅ What Uniswap Has That We Use
|
||||
|
||||
1. **Official Schema**
|
||||
- JSON Schema from `@uniswap/token-lists`
|
||||
- TypeScript type definitions
|
||||
- Standard specification compliance
|
||||
|
||||
2. **Package Ecosystem**
|
||||
- npm package for easy integration
|
||||
- Type definitions for TypeScript projects
|
||||
- Schema validation utilities
|
||||
|
||||
---
|
||||
|
||||
## Code Comparison
|
||||
|
||||
### Schema Access
|
||||
|
||||
**Uniswap Approach:**
|
||||
```typescript
|
||||
import { schema } from '@uniswap/token-lists'
|
||||
import { TokenList, TokenInfo } from '@uniswap/token-lists'
|
||||
```
|
||||
|
||||
**Our Approach (Before):**
|
||||
```javascript
|
||||
const SCHEMA_URL = 'https://uniswap.org/tokenlist.schema.json';
|
||||
const schema = await fetch(SCHEMA_URL).then(r => r.json());
|
||||
```
|
||||
|
||||
**Our Approach (After):**
|
||||
```javascript
|
||||
import { schema } from '@uniswap/token-lists';
|
||||
// Falls back to URL fetch if package unavailable
|
||||
```
|
||||
|
||||
### Validation
|
||||
|
||||
**Uniswap Approach:**
|
||||
```typescript
|
||||
import Ajv from 'ajv';
|
||||
import addFormats from 'ajv-formats';
|
||||
import { schema } from '@uniswap/token-lists';
|
||||
|
||||
const ajv = new Ajv({ allErrors: true, verbose: true });
|
||||
addFormats(ajv);
|
||||
const validate = ajv.compile(schema);
|
||||
const valid = validate(tokenList);
|
||||
```
|
||||
|
||||
**Our Approach:**
|
||||
```javascript
|
||||
// Uses @uniswap/token-lists schema + enhanced validation
|
||||
const schema = await getSchema(); // From package or URL
|
||||
const validate = ajv.compile(schema);
|
||||
const valid = validate(tokenList);
|
||||
|
||||
// Plus additional checks:
|
||||
// - EIP-55 checksum validation
|
||||
// - Duplicate detection
|
||||
// - Chain ID strict validation
|
||||
// - Logo URL validation
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices Alignment
|
||||
|
||||
### ✅ We Follow Uniswap Best Practices
|
||||
|
||||
1. **Semantic Versioning**
|
||||
- ✅ Major: token removals
|
||||
- ✅ Minor: token additions
|
||||
- ✅ Patch: metadata updates
|
||||
|
||||
2. **File Naming**
|
||||
- ✅ `.tokenlist.json` extension for schema validation
|
||||
|
||||
3. **Schema Compliance**
|
||||
- ✅ All required fields
|
||||
- ✅ Optional fields where appropriate
|
||||
- ✅ Proper tag definitions
|
||||
|
||||
4. **Hosting**
|
||||
- ✅ HTTPS endpoints
|
||||
- ✅ CORS headers configured
|
||||
- ✅ Public accessibility
|
||||
|
||||
### ✅ We Enhance Beyond Uniswap
|
||||
|
||||
1. **Validation Rigor**
|
||||
- Stricter validation than base spec
|
||||
- On-chain verification
|
||||
- Security checks
|
||||
|
||||
2. **Automation**
|
||||
- CI/CD integration
|
||||
- Automated releases
|
||||
- Signature generation
|
||||
|
||||
3. **Documentation**
|
||||
- Comprehensive guides
|
||||
- Policy documentation
|
||||
- Integration examples
|
||||
|
||||
---
|
||||
|
||||
## Integration Status
|
||||
|
||||
### ✅ Completed
|
||||
|
||||
- [x] Added `@uniswap/token-lists` package dependency
|
||||
- [x] Updated validation script to use package schema
|
||||
- [x] Maintained fallback to URL fetch
|
||||
- [x] Enhanced validation beyond base spec
|
||||
- [x] TypeScript types available for future use
|
||||
|
||||
### 🔄 Available But Not Required
|
||||
|
||||
- [ ] TypeScript migration (current scripts are JavaScript)
|
||||
- [ ] Direct type imports in validation scripts
|
||||
- [ ] Token list registry integration
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
### ✅ Implemented
|
||||
|
||||
1. **Use Official Package** ✅
|
||||
- Now using `@uniswap/token-lists` for schema
|
||||
- Maintains compatibility with specification
|
||||
|
||||
2. **Enhanced Validation** ✅
|
||||
- Kept our enhanced validation features
|
||||
- Adds value beyond base specification
|
||||
|
||||
3. **Type Safety** ✅
|
||||
- TypeScript types available from package
|
||||
- Can be used in TypeScript projects
|
||||
|
||||
### 💡 Future Enhancements
|
||||
|
||||
1. **TypeScript Migration**
|
||||
- Convert validation scripts to TypeScript
|
||||
- Use `TokenList` and `TokenInfo` types directly
|
||||
|
||||
2. **Token List Registry**
|
||||
- Consider creating a registry similar to Uniswap's
|
||||
- Enable discovery and aggregation
|
||||
|
||||
3. **Automated Token Discovery**
|
||||
- Explore DefiLlama adapter patterns
|
||||
- Auto-populate from on-chain data
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
Our implementation:
|
||||
|
||||
- ✅ **Complies** with Uniswap Token Lists specification
|
||||
- ✅ **Uses** official `@uniswap/token-lists` package
|
||||
- ✅ **Enhances** with additional validation and security
|
||||
- ✅ **Maintains** backward compatibility
|
||||
- ✅ **Provides** comprehensive tooling and documentation
|
||||
|
||||
**Status**: Fully aligned with Uniswap specification while providing enhanced features for production use.
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: 2026-01-26
|
||||
Reference in New Issue
Block a user