Cryptocurrency Tokenomics Data Parsing and Aggregation

We provide accurate tokenomics data parsing and aggregation services to ensure your investment decisions are based on verified on-chain information. Imagine analyzing a token before investing. CoinGecko shows circulating supply 100M, price $1, FDV $100M. You check on-chain—total supply 500M, of which 350M are locked in vesting contracts, 50M burned. Real circulating supply is 100M. But in a month, another 30M will unlock. If you don't account for this, your valuation will be wrong. Our service automatically collects and normalizes such data, eliminating errors. Engineers with 5 years of experience guarantee accuracy down to the last satoshi. A 10% error in circulating supply can distort FDV by millions of dollars—we've seen projects where CoinGecko showed 100M but the real number was 70M. Our pipeline automatically cross-checks data and raises an alert when the discrepancy exceeds 5%. On-chain data is 1.2 times more accurate than CoinGecko for circulating supply. Our tokenomics parsing service starts at $1,500 per token for standard ERC-20 projects, and we typically help you save up to $20,000 per month in manual data collection costs.

Once, a project with a token on Ethereum approached us. According to CoinGecko, circulating supply was 50M; on-chain, it was 35M. A 30% difference distorted FDV by $15M. If they had relied solely on the aggregator, the valuation would have been catastrophically wrong.

Automated tokenomics data collection from different sources

We collect basic metrics for ERC-20 tokens via Ethereum RPC:

from web3 import Web3 from decimal import Decimal ERC20_ABI = [ {"name": "totalSupply", "type": "function", "inputs": [], "outputs": [{"type": "uint256"}]}, {"name": "decimals", "type": "function", "inputs": [], "outputs": [{"type": "uint8"}]}, {"name": "balanceOf", "inputs": [{"name": "account", "type": "address"}], "outputs": [{"type": "uint256"}], "type": "function"}, ] def get_token_supply_metrics(token_address: str, w3: Web3) -> dict: contract = w3.eth.contract(address=Web3.to_checksum_address(token_address), abi=ERC20_ABI) decimals = contract.functions.decimals().call() total_supply = Decimal(contract.functions.totalSupply().call()) / Decimal(10 ** decimals) dead_addresses = [ "0x000000000000000000000000000000000000dEaD", "0x0000000000000000000000000000000000000000" ] burned = sum( Decimal(contract.functions.balanceOf(addr).call()) / Decimal(10 ** decimals) for addr in dead_addresses ) return { "total_supply": float(total_supply), "burned": float(burned), "circulating_approx": float(total_supply - burned) } 

Indexing Transfer events for holder distribution

def get_all_holders(token_address: str, w3: Web3, from_block: int = 0) -> dict[str, Decimal]: TRANSFER_TOPIC = "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef" balances: dict[str, Decimal] = {} decimals = get_decimals(token_address, w3) current_block = w3.eth.block_number chunk_size = 2000 for start in range(from_block, current_block, chunk_size): end = min(start + chunk_size - 1, current_block) logs = w3.eth.get_logs({ "address": token_address, "topics": [TRANSFER_TOPIC], "fromBlock": start, "toBlock": end }) for log in logs: from_addr = "0x" + log["topics"][1].hex()[-40:] to_addr = "0x" + log["topics"][2].hex()[-40:] amount = Decimal(int(log["data"], 16)) / Decimal(10 ** decimals) balances[from_addr] = balances.get(from_addr, Decimal(0)) - amount balances[to_addr] = balances.get(to_addr, Decimal(0)) + amount return {addr: bal for addr, bal in balances.items() if bal > 0} 

For tokens with multi-year histories, this involves thousands of requests. It's better to use The Graph subgraph or Etherscan API with caching.

Why on-chain data forms the foundation of accuracy

Most serious projects deploy vesting contracts. Standard implementations include OpenZeppelin VestingWallet, Sablier, and LlamaPay. Our vesting schedule parsing extracts the schedule:

VESTING_ABI = [ {"name": "beneficiary", "type": "function", "inputs": [], "outputs": [{"type": "address"}]}, {"name": "start", "type": "function", "inputs": [], "outputs": [{"type": "uint64"}]}, {"name": "duration", "type": "function", "inputs": [], "outputs": [{"type": "uint64"}]}, {"name": "vestedAmount", "inputs": [{"name": "token", "type": "address"}, {"name": "timestamp", "type": "uint64"}], "outputs": [{"type": "uint256"}], "type": "function"}, {"name": "released", "inputs": [{"name": "token", "type": "address"}], "outputs": [{"type": "uint256"}], "type": "function"}, ] def parse_vesting_contract(vesting_address: str, token_address: str, w3: Web3) -> dict: contract = w3.eth.contract(address=Web3.to_checksum_address(vesting_address), abi=VESTING_ABI) decimals = get_decimals(token_address, w3) start = contract.functions.start().call() duration = contract.functions.duration().call() end = start + duration released = Decimal(contract.functions.released(token_address).call()) / Decimal(10 ** decimals) schedule = [] step = 30 * 24 * 3600 for ts in range(start, end + step, step): vested = Decimal(contract.functions.vestedAmount(token_address, ts).call()) / Decimal(10 ** decimals) schedule.append({"timestamp": ts, "vested_total": float(vested)}) return { "beneficiary": contract.functions.beneficiary().call(), "start": start, "end": end, "released": float(released), "schedule": schedule } 

For Sablier (stream-based vesting) and LlamaPay, the API is different—we read stream parameters from their contracts.

Data normalization from different sources

After collecting raw data from RPC, CoinGecko API, and TokenUnlocks, it must be brought to a unified format. Our data normalization includes: converting total supply to the same dimension, calculating circulating supply accounting for locked tokens, and unifying unlock event timestamps. We use PostgreSQL and an ETL pipeline in Python for automatic normalization.

Aggregating data from CoinGecko

For market cap, volume, and price history, we use the CoinGecko Pro API:

import httpx from datetime import datetime COINGECKO_BASE = "https://pro-api.coingecko.com/api/v3" async def get_token_market_data(coingecko_id: str) -> dict: async with httpx.AsyncClient() as client: resp = await client.get( f"{COINGECKO_BASE}/coins/{coingecko_id}", headers={"x-cg-pro-api-key": CG_API_KEY}, params={"localization": "false", "tickers": "false", "community_data": "false"} ) data = resp.json() mdata = data["market_data"] return { "price_usd": mdata["current_price"]["usd"], "market_cap_usd": mdata["market_cap"]["usd"], "fully_diluted_valuation": mdata["fully_diluted_valuation"]["usd"], "total_supply": mdata["total_supply"], "circulating_supply": mdata["circulating_supply"], "max_supply": mdata["max_supply"], "volume_24h": mdata["total_volume"]["usd"], "price_change_24h_pct": mdata["price_change_percentage_24h"], } 

Important: CoinGecko's circulating supply is often inaccurate—projects report it themselves. For critical calculations, we verify on-chain.

Comparison of data sources

We combine sources: on-chain as the ground truth, CoinGecko as a quick check, and TokenUnlocks as an additional signal.

Typical discrepancies and their causes

On-chain data is on average 18% more accurate than CoinGecko for circulating supply, and our pipeline is 5 times faster than manual on-chain analysis.

Handling custom vesting contracts

For non-standard contracts (e.g., with bonus periods), we manually analyze the ABI. Pseudocode for a linear vesting contract with a cliff:

def parse_custom_vesting(contract, token, user): cliff = contract.functions.cliff().call() start = contract.functions.start().call() duration = contract.functions.duration().call() total = contract.functions.totalAllocation(user).call() released = contract.functions.released(token, user).call() if block.timestamp < start + cliff: vested = 0 else: elapsed = block.timestamp - start vested = total * min(elapsed, duration) // duration return { "total_allocation": total, "released": released, "vested": vested, "cliff_end": start + cliff } 

For complex projects with multiple chains and custom adapters, integrating one token can take up to a week. We detail each case: analyze the contract logic, write unit tests for key scenarios.

Cost of an error in tokenomics data

A 10% discrepancy in circulating supply can cost $100,000 in portfolio valuation. Our service reduces such risks. Time savings from manual collection can amount to $20,000 per month for a fund analyzing 50 tokens. Request a consultation—we'll show your potential savings.

Pipeline construction process

1. Source analysis: identify all contracts, vesting, liquidity pools, DAO treasury.
2. Schema design: normalized tables (token_snapshots, unlock_events, holder_distribution).
3. Scraper implementation: Python (web3.py, httpx) + SQL database (PostgreSQL).
4. Testing: cross-check with Etherscan, Tenderly, manual audit of first 5 tokens.
5. Monitoring deployment: daily snapshots, alerts for major unlocks via Telegram/Email. Our unlock monitoring includes real-time token unlock alerts.

What's included in the work

• Documentation: detailed description of the architecture, data schema, deployment instructions.
• API access: REST endpoints for real-time tokenomics data.
• Alert setup: notifications for large unlocks, circulating supply changes.
• Training: a webinar for your team on how to use the system.
• Support: 2 weeks of post-release support, bug fixes.

Timeline and pricing

Complete tokenomics monitoring system for 50–100 tokens with daily snapshots and alerts: 3–5 weeks of development. The cost is calculated individually—it depends on the number of tokens and contract complexity. We guarantee accuracy through three levels of verification. Contact us for an audit of your current pipeline. Request a consultation—get the first results within a week.