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.

Blockchain Infrastructure Deployment: Nodes, RPC, Indexing

Subgraph fell at 3:47 AM. By morning users saw outdated balances, transactions "hung" in the UI, support received 47 tickets in an hour. Cause: the handler in the subgraph failed on a transaction with a non-standard event log — and the entire index stopped. We have encountered such situations dozens of times. Our experience shows: blockchain infrastructure does not forgive gaps in observability. Guaranteeing uptime without multi-layered monitoring and fault-tolerant architecture is impossible. Over 8 years working with Ethereum, Polygon, and Solana, we have developed an approach that allows predictable deployment of infrastructure of any scale — from a single node to a multichain grid with dozens of subgraphs.

RPC Layer Architecture

Every dApp interaction with the blockchain goes through RPC — the JSON-RPC API provided by a node. Three options:

Managed providers — Alchemy, QuickNode, Infura, Ankr. Minimal operational costs, SLA, built-in monitoring. Limits: rate limits (Alchemy Free: 300 RU/sec), vendor lock, potential downtime during provider incidents. For most projects — the right choice at the start.

Self-owned nodes — full control, no rate limits, no third-party dependence. Cost: archive Ethereum node requires 2.5–3TB SSD, a strong server, and DevOps support. Sync from scratch on Ethereum via Geth/Nethermind — 3–7 days. Justified under high load or latency requirements.

Hybrid — self-owned node as primary, managed provider as fallback. Standard for protocols with high TVL. Proper load balancing can reduce costs by 20–30% compared to pure managed setup. Under high monthly request volume, hybrid saves significantly.

How to Set Up an RPC Layer Without a Single Point of Failure?

At least two providers, DNS round-robin with health check every 5 seconds, automatic fallback when latency >500 ms. In practice, this gives 99.99% availability during any provider failure. For protocols with high TVL, we recommend a custom HA-proxy (nginx or Envoy) in front of two managed providers.

Why Is a Hybrid RPC Scheme More Cost-Effective Than Pure Managed?

At high request volumes, managed providers can be very expensive; a hybrid using a self-owned node as primary and a managed fallback cuts costs significantly without losing SLA.

Ethereum Node Clients

Execution clients: Geth (most used), Nethermind (C#, fast sync), Besu (Java, enterprise), Erigon (fastest sync, efficient archive mode ~2TB instead of 3TB).

Consensus clients (post-Merge): Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim). Each node after The Merge requires a pair of execution + consensus clients.

For DevOps: eth-docker — Docker Compose configurations for all client combinations. Setting up monitoring via Grafana + Prometheus is mandatory; a standard dashboard is available in each client's repository.

The Graph: Event Indexing

The Graph Protocol — decentralized indexing. A subgraph describes which events from which contracts to index and how to transform them into a GraphQL schema.

Subgraph structure:

• subgraph.yaml — manifest: contract addresses, startBlock, events to handle
• schema.graphql — GraphQL schema of entities
• src/mapping.ts — AssemblyScript event handlers

dataSources:
  - kind: ethereum
    name: UniswapV3Pool
    network: mainnet
    source:
      address: "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640"
      abi: UniswapV3Pool
      startBlock: 12370624
    mapping:
      eventHandlers:
        - event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
          handler: handleSwap

AssemblyScript handlers — not TypeScript. No nullable types, no closures, no many standard APIs. An error in the handler stops the subgraph indexing on that transaction. Important: add try-catch for operations that can fail (e.g., store.get() for an entity that may not exist).

How to Avoid Subgraph Indexing Stops?

Graph Node logs are monitored in real-time; on hasIndexingErrors = true an alert fires and an automatic node restart (via systemd or Kubernetes). Typical downtime on error — 150–300 seconds to recover. Additionally, for production we set up a watchdog that restarts Graph Node if subgraph lag exceeds 50 blocks.

Choosing Between Hosted Service and Decentralized Network

Graph Hosted Service (free, centralized) is deprecated in favor of Subgraph Studio + Graph Network. For production: deploy on Graph Network with GRT curation signal — the subgraph gets indexers proportional to curation.

Alternatives to The Graph: Ponder (TypeScript, self-hosted, easier to debug), Envio (ultra-fast indexer, supports EVM + non-EVM), Subsquid (TypeScript, own network), Moralis Streams (managed, webhook-based). Our experience shows: for high-load projects with unique logic, Ponder or Envio are more effective — they give full control over the process and do not require GRT tokenomics.

Webhooks and Real-Time Notifications

Alchemy Webhooks and QuickNode Streams allow receiving events in real-time via HTTP webhook or WebSocket. For monitoring addresses, new transactions, mints — this is faster than polling RPC.

Tenderly — platform for monitoring and alerts. You can set up an alert for a specific contract event, balance change, function call with certain parameters. Transaction simulation via Tenderly API is invaluable for debugging.

Monitoring and Observability

Minimum monitoring stack for a protocol:

On-chain: OpenZeppelin Defender Sentinel — watches contract events, triggers webhook or Autotask when conditions are met. Forta Network — community-maintained bots detect anomalies (large withdrawals, flash loans, governance attacks).

Infrastructure: Grafana + Prometheus for nodes, Datadog or Grafana Cloud for managed metrics. Alerts on: node is 10+ blocks behind, RPC latency >500ms, subgraph lag >100 blocks.

Uptime: Better Uptime or PagerDuty on RPC endpoint and subgraph health endpoint (The Graph provides _meta { hasIndexingErrors, block { number } }).

Why Is Monitoring Without Tenderly Insufficient?

Tenderly provides transaction simulation and detailed traces — critical for debugging subgraph and smart contract errors. Forta focuses on network anomalies, not your infrastructure. The combination of Tenderly plus a custom Grafana dashboard covers 90% of incident scenarios.

Multichain Infrastructure

A protocol on 5 chains = 5 separate RPC endpoints, 5 subgraphs, 5 monitoring configs. Manageable but requires deployment automation.

For subgraph multi-network deployment: graph deploy --network mainnet, graph deploy --network arbitrum-one etc. with a unified codebase and network-specific addresses in separate config files.

Chainlink CCIP and LayerZero for cross-chain messaging require monitoring of both chains and transactions on intermediate relayers. A reorg on the source chain after a confirmed mint on the target chain is a classic bridge problem. Solution: wait for finality (on Ethereum ~15 minutes after Merge for economic finality) before confirming on the target chain.

Infrastructure Setup Process

1. Audit current stack — determine chains, request volume, latency and availability requirements.
2. Architecture design — select providers, load balancing, redundancy.
3. Subgraph development — manifest → schema → handlers → testing on local Graph Node → deploy to testnet → mainnet.
4. Monitoring configuration — Tenderly alerts, Grafana dashboard, PagerDuty integration.
5. Documentation and runbook — what to do when: subgraph falls behind, RPC downtime, node desync.
6. Handover to operations — team training, access transfer, first month support.

What's Included

• Deployment of managed or self-hosted Ethereum, Polygon, BNB Chain nodes
• RPC layer setup with primary/fallback and load balancing
• Subgraph development and deployment for your protocol
• Monitoring connection (Tenderly, Grafana, alerts)
• Runbook and operations documentation
• Team training (up to 4 hours online)
• 30-day support after delivery

Timeline

All projects are managed in a GitHub/GitLab repository with CI/CD; configuration code stays with you. Order infrastructure deployment — we'll show how to cut costs by 20–30% without losing reliability. Get a consultation — we'll demonstrate how we deployed infrastructure for a protocol with large TVL on Ethereum and Arbitrum. Contact us.