Analyzing Historical Pool Performance On-Chain

LABS

Analyzing Historical Pool Performance On-Chain

Core Concepts for Historical Analysis

Foundational on-chain data concepts required to accurately interpret and evaluate historical DeFi pool performance.

Reserve Balances & Price Impact

Reserve balances are the real-time token quantities held by a liquidity pool. Analyzing their historical changes reveals capital flows and concentration risks.

Tracks impermanent loss drivers and pool health over time.
Large swaps cause significant price impact, calculated as (Δx / x_reserve).
Essential for modeling historical slippage and understanding arbitrage opportunities that rebalanced the pool.

Volume & Fee Generation

Swap volume represents the total value of assets traded through a pool in a period. This directly determines the protocol fees earned by liquidity providers.

High volume with low TVL indicates efficient capital utilization.
Fee data is critical for calculating historical APY and ROI.
Analyzing volume spikes can correlate with market events or new integrations.

Tick Liquidity & Concentrated Ranges

For concentrated liquidity AMMs like Uniswap V3, liquidity is allocated within specific price ticks. Historical analysis must map liquidity distribution across the price curve.

Reveals where LPs anticipated price action and their realized fees.
Tracks capital efficiency versus full-range pools.
Critical for backtesting strategy performance and understanding impermanent loss in bounded ranges.

Timestamped Block Data

All on-chain events are permanently recorded with a block number and timestamp. Consistent time-series analysis depends on correctly querying and aligning this data.

Enables calculation of daily/weekly metrics like volume and TVL.
Must account for variable block times (e.g., Ethereum ~13s, Polygon ~2s).
Foundational for creating comparable historical charts and performance benchmarks.

LP Token Valuation

The value of a liquidity provider token represents a share of the pool's total reserves. Its historical price is not constant but derived from the underlying assets.

Tracking LP token value versus holding assets quantifies impermanent loss.
Requires historical price oracles for each reserve asset.
Essential for calculating the true historical return of providing liquidity.

Event Logs & Contract Interactions

Smart contract event logs (e.g., Swap, Mint, Burn) are the raw source for historical analysis. Each log contains indexed and non-indexed data parameters.

Swap events provide volume, reserve updates, and fee data.
Mint/Burn events track LP capital inflows and outflows.
Parsing these logs allows reconstruction of any pool's complete historical state.

Extracting Historical Pool Data

Process for programmatically retrieving and structuring historical liquidity pool metrics from on-chain sources.

Identify Data Sources and Access Methods

Determine the on-chain and off-chain data providers for historical pool states.

Detailed Instructions

First, identify the primary data sources for the pool you are analyzing. For live on-chain queries, use the pool's factory contract or the specific pool contract address to call functions like getReserves() on Uniswap V2 or slot0() on Uniswap V3. For historical data, you will need to query a blockchain node archive or a specialized indexer. Services like The Graph host subgraphs for major protocols (e.g., Uniswap, Balancer, Curve) that index historical events like swaps, mints, and burns. Alternatively, use an RPC provider with archive node access to call eth_getLogs for specific event signatures over a block range. For a Uniswap V2 pair at 0x..., the Sync event logs the reserve updates.

Sub-step 1: Locate the pool's contract address and ABI.
Sub-step 2: Determine if a canonical subgraph exists for the protocol.
Sub-step 3: Verify your node or API provider supports historical state queries.

javascript
// Example: Getting reserves from a Uniswap V2 pair contract
const reserves = await pairContract.getReserves();
console.log(`Reserve0: ${reserves[0]}, Reserve1: ${reserves[1]}`);

Tip: For efficiency, use subgraphs for aggregated historical data and direct contract calls for specific, real-time state checks.

Query Historical Pool State via Event Logs

Extract granular state changes by filtering and parsing blockchain event logs.

Detailed Instructions

Pool state changes are emitted as event logs. To reconstruct history, you must query these logs. The core events are Mint, Burn, and Swap. Use eth_getLogs JSON-RPC call with a filter for the pool address and event signatures. For a Uniswap V2-style Sync(uint112 reserve0, uint112 reserve1) event, the signature topic is keccak256('Sync(uint112,uint112)'). You need to specify a block range; for long histories, batch requests to avoid timeout. Parse the returned log data and topics to extract the reserve values and calculate derived metrics like price and liquidity for each block. Store the timestamp of each block by making a separate call to eth_getBlockByNumber.

Sub-step 1: Calculate the event signature hashes (topics) for Mint, Burn, and Swap.
Sub-step 2: Construct the eth_getLogs filter with address, topics, and fromBlock/toBlock.
Sub-step 3: Decode the non-indexed data from the data field using the contract ABI.

bash
# Example curl request for Sync events
curl -X POST https://eth-mainnet.g.alchemy.com/v2/your-key \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"address": "0xa478c2975ab1ea89e8196811f51a7b7ade33eb11", "topics": ["0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1"], "fromBlock": "0xFA1234", "toBlock": "0xFA5678"}], "id":1}'

Tip: Be mindful of RPC rate limits and cost when querying large block ranges. Use batch processing and consider using a dedicated indexer for production applications.

Calculate Derived Metrics from Raw Data

Transform raw reserve and event data into actionable performance metrics.

Detailed Instructions

With historical reserves and volumes, calculate key performance metrics. The primary metric is the pool's asset price, calculated as reserve1 / reserve0 (or vice versa, depending on quote currency). Track liquidity depth as the product of the reserves (k for constant product pools). Calculate swap volume per block by summing the amount0In/Out and amount1In/Out from Swap events, converting to a common USD value using historical price oracles. Compute impermanent loss for a liquidity position by comparing the value of held assets if they were simply held versus provided to the pool, using the price change between two timestamps. For fee calculation, apply the pool's fee percentage (e.g., 0.3%) to the volume.

Sub-step 1: For each timestamp, calculate the spot price and sqrt(k) liquidity.
Sub-step 2: Aggregate Swap event amounts to derive hourly/daily trading volume.
Sub-step 3: Implement impermanent loss formula: IL = (value_in_pool / value_held) - 1.

python
# Example: Calculating impermanent loss for a 2-asset pool
def impermanent_loss(price_ratio_change):
    # price_ratio_change = P_t / P_0
    return 2 * (price_ratio_change**0.5) / (1 + price_ratio_change) - 1

# If price of asset A doubles relative to asset B (change = 2)
il = impermanent_loss(2)  # Result: ~-5.72%

Tip: Use precise decimal math libraries (e.g., ethers.js BigNumber, Python's Decimal) to avoid floating-point errors in financial calculations.

Structure and Store the Dataset

Organize the extracted time-series data into a queryable format for analysis.

Detailed Instructions

Organize the processed data into a structured time-series dataset. Each record should represent a pool state at a specific block and include fields: timestamp, block number, reserve amounts, derived price, liquidity metric, and cumulative volume up to that block. For granular analysis, you may also store individual event records (swaps, mints). Choose a storage backend suitable for time-series queries, such as a SQL database with timestamp indexing, a dedicated TSDB like InfluxDB, or simply compressed CSV/Parquet files. Ensure the schema includes the pool address and token identifiers. This structure enables efficient queries for historical price charts, volatility analysis, and correlation studies with other market data.

Sub-step 1: Define a database schema or file structure with necessary fields.
Sub-step 2: Write the calculated metrics from each block into the storage.
Sub-step 3: Create indexes on timestamp and pool address for fast retrieval.

sql
-- Example SQL table schema for pool states
CREATE TABLE pool_states (
    id SERIAL PRIMARY KEY,
    pool_address CHAR(42) NOT NULL,
    block_number BIGINT NOT NULL,
    timestamp TIMESTAMP NOT NULL,
    reserve0 DECIMAL(38, 18),
    reserve1 DECIMAL(38, 18),
    price DECIMAL(38, 18),
    liquidity DECIMAL(38, 18),
    cumulative_volume_usd DECIMAL(38, 2)
);
CREATE INDEX idx_pool_time ON pool_states (pool_address, timestamp);

Tip: Regularly backfill and update your dataset. Consider using a workflow manager (e.g., Apache Airflow) to schedule incremental updates from the latest block.

Validate Data Integrity and Consistency

Implement checks to ensure the extracted data is accurate and free from gaps or errors.

Detailed Instructions

Data validation is critical for reliable analysis. Implement consistency checks. First, verify event log continuity; ensure there are no unexpected gaps in block numbers for a pool's major events. Cross-validate metrics: the change in reserves between two states should equal the net sum of Mint, Burn, and Swap events in that interval. Use invariant checks; for a constant product pool, the product reserve0 * reserve1 should only increase from fees (via Swap events) within a tolerance. Compare your derived price against a trusted external oracle or aggregate price feed for sanity checking. Check for reorgs by validating block hashes if your data is very recent. Automate these checks to flag discrepancies for manual review.

Sub-step 1: Run a script to detect missing blocks in your event sequence.
Sub-step 2: Recalculate reserve changes from event sums and compare to on-chain state diffs.
Sub-step 3: Validate the constant product invariant (k) increases only when fees are accrued.

javascript
// Example: Validating reserve changes against event sums
// pseudo-code for interval between block N and N+100
const calculatedReserveChange = eventsSum(Mint) - eventsSum(Burn) + netSwapImpact;
const actualReserveChange = reserveAtBlockN+100 - reserveAtBlockN;
if (Math.abs(calculatedReserveChange - actualReserveChange) > tolerance) {
    throw new Error('Data inconsistency detected');
}

Tip: Set up alerting for validation failures. Inconsistencies may indicate issues with your RPC provider, a subgraph sync error, or a chain reorg you need to handle.

Performance Metric Frameworks

Foundational Metrics

Performance analysis for on-chain liquidity pools requires moving beyond simple APY. The primary metrics are Total Value Locked (TVL), volume, and fees generated. TVL indicates capital commitment but is a lagging indicator. Volume shows user activity and potential fee revenue. The fee-to-TVL ratio is a key efficiency metric, measuring how much revenue a pool generates relative to its size.

Key Metrics to Track

Annual Percentage Yield (APY): Often misleading; decompose into fee-based yield vs. token incentives.
Impermanent Loss (IL): Quantify divergence loss relative to a simple HODL strategy for liquidity providers.
Capital Efficiency: Measured as trading volume divided by TVL; higher ratios indicate better pool utilization.

Practical Example

When analyzing a Uniswap v3 ETH/USDC pool, track its 30-day fee yield, compare its volume/TVL ratio to similar pools, and model IL under different price volatility scenarios to assess true provider returns.

Calculating Historical Impermanent Loss

Process for quantifying the opportunity cost of providing liquidity versus holding assets.

Extract Historical Pool State and Asset Prices

Query on-chain data to get the pool's reserve composition and external market prices at specific past timestamps.

Detailed Instructions

To calculate impermanent loss, you need a snapshot of the pool's state and the external market price of the assets at the same historical point. For a Uniswap V2-style pool, query the pair contract's getReserves() function at the target block. You'll also need the market price of each token, which is not stored on-chain. Use a decentralized oracle's historical price feed (e.g., Chainlink's AggregatorV3Interface) or query a price from a high-liquidity centralized pool like WETH/USDC.

Sub-step 1: Use a node provider (Alchemy, Infura) with archive access to call getReserves() on the pool contract (e.g., 0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11 for UNI/ETH) at block number 12345678.
Sub-step 2: Fetch the historical ETH/USD price from a Chainlink aggregator (0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419) for the same block using getRoundData().
Sub-step 3: Convert the reserve amounts into a common value (USD) using the fetched prices to establish the portfolio value if held.

javascript
// Example using ethers.js to get reserves
const reserves = await pairContract.getReserves({ blockTag: targetBlock });
const reserveA = reserves[0];
const reserveB = reserves[1];

Tip: For accurate IL, the market price must be sourced independently from the AMM pool you're analyzing to avoid circular reference.

Calculate Portfolio Value if Held (HODL Value)

Compute the value the initial liquidity deposit would have had if simply held outside the pool.

Detailed Instructions

The HODL value represents the benchmark. First, determine your initial deposit amounts of Token A and Token B. If you don't have this, you can simulate a standard LP position, such as providing 1 ETH and the corresponding amount of the paired token to make the pool 50/50 in value at the initial time. Use the historical market prices from Step 1 to value these held amounts.

Sub-step 1: Define your initial LP share. For a simulation, calculate the token amounts needed for a balanced deposit: amountTokenB = (amountTokenA * priceTokenA) / priceTokenB.
Sub-step 2: Value the held position at the current historical timestamp: hodlValue = (initialAmountA * priceA_now) + (initialAmountB * priceB_now).
Sub-step 3: Value the held position at the future historical timestamp you are analyzing using the new market prices. The change in HODL value shows pure price appreciation.

python
# Python pseudocode for HODL value
initial_eth = 1.0
initial_token_amount = (initial_eth * eth_price_initial) / token_price_initial

hodl_value_future = (initial_eth * eth_price_future) + (initial_token_amount * token_price_future)

Tip: This calculation assumes no fees or rewards. For a real user's position, you would need their exact minted LP share from a Mint event.

Calculate Portfolio Value in the Pool (LP Value)

Determine the value of the liquidity provider's share of the pool reserves at the historical point.

Detailed Instructions

The LP value is the value of your share of the pool's reserves at the specific block. You need your pool share percentage, derived from the total supply of LP tokens. Query the pool's totalSupply() and your balanceOf() at the block. Your share of each reserve is (yourLPTokens / totalLPTokens) * reserveAmount. Then, value those amounts using the current market prices (not the pool's implied price).

Sub-step 1: Call balanceOf(yourAddress) and totalSupply() on the LP token contract at the target block to get your share: share = yourBalance / totalSupply.
Sub-step 2: Apply this share to the reserves obtained in Step 1: yourReserveA = share * reserveA.
Sub-step 3: Calculate the LP value: lpValue = (yourReserveA * marketPriceA) + (yourReserveB * marketPriceB).

solidity
// Solidity view function logic for calculation
function getLPValue(uint lpBalance, uint blockNumber) public view returns (uint value) {
    (uint reserve0, uint reserve1,) = pair.getReserves();
    uint totalSupply = pair.totalSupply();
    uint share = (lpBalance * 1e18) / totalSupply; // Precision
    uint myReserve0 = (reserve0 * share) / 1e18;
    uint myReserve1 = (reserve1 * share) / 1e18;
    value = (myReserve0 * oraclePrice0) + (myReserve1 * oraclePrice1);
}

Tip: Use the same external market prices from Step 1 for valuation to ensure a fair comparison to the HODL scenario.

Compute Impermanent Loss Ratio and Absolute Value

Derive the percentage and USD amount of loss/gain relative to the holding strategy.

Detailed Instructions

Impermanent Loss (IL) is the difference between the LP value and the HODL value, expressed as a ratio of the HODL value. A negative result indicates a loss versus holding. The formula is: IL = (LP_Value - HODL_Value) / HODL_Value. Multiply by 100 for a percentage. The absolute loss in USD is LP_Value - HODL_Value.

Sub-step 1: Perform the final calculation: il_ratio = (lp_value - hodl_value) / hodl_value.
Sub-step 2: For a standard 50/50 pool, you can also use the simplified formula based on price ratio change r = p1 / p0: IL = 2 * sqrt(r) / (1+r) - 1. Verify your on-chain result matches this model.
Sub-step 3: Contextualize the result. An IL of -5% means the LP's portfolio is worth 5% less than if they had just held the tokens, excluding fees.

python
# Calculate IL from the derived values
impermanent_loss_ratio = (lp_value - hodl_value) / hodl_value
impermanent_loss_usd = lp_value - hodl_value

# Theoretical IL based on price change
price_ratio = price_token_future / price_token_initial
theoretical_il = (2 * math.sqrt(price_ratio)) / (1 + price_ratio) - 1

Tip: Remember, this is 'impermanent' because the loss is unrealized until you withdraw. If prices revert, the loss diminishes.

Adjust for Accumulated Fees and Rewards

Factor in trading fees and liquidity incentives to get net performance.

Detailed Instructions

The raw IL calculation ignores fees earned, which can offset losses. To get the net PnL, you must add accumulated fees to the LP value. For Uniswap V2, fees are auto-compounded into the pool reserves, increasing the value of each LP token. Estimate fees by tracking the growth in your LP token's underlying reserve share beyond what price movement alone would cause. Alternatively, sum all Swap events to estimate total fees generated and your share.

Sub-step 1: Calculate the LP value including fee accrual. One method is to compare your LP token's proportional share of reserves at Time 0 and Time T. The increase not explained by IL is roughly fees.
Sub-step 2: For incentive programs (e.g., SUSHI rewards), query the distributor contract to sum claimable or historically claimed tokens for your address.
Sub-step 3: Compute final performance: Net Performance = (LP_Value_With_Fees + Reward_Value) - HODL_Value.

javascript
// Estimating fee accrual by comparing LP token value growth
const initialShare = initialLPTokens / initialTotalSupply;
const initialShareValue = initialShare * (reserveA0*priceA0 + reserveB0*priceB0);

const currentShare = currentLPTokens / currentTotalSupply;
const currentShareValue = currentShare * (reserveA1*priceA1 + reserveB1*priceB1);

// The value increase beyond price movement hints at fees
const estimatedFeesValue = currentShareValue - (initialShareValue * (1 + theoretical_il));

Tip: Precise fee attribution is complex. For a simpler analysis, use analytics platforms like Dune Analytics that have pre-built fee queries for major pools.

Tools for On-Chain Pool Analysis

Comparison of platforms for historical liquidity pool data querying and analysis.

Feature	Dune Analytics	Flipside Crypto	The Graph
Primary Data Source	EVM Chain RPC Nodes	EVM Chain RPC Nodes	Subgraph Indexers
Query Language	SQL (SparkSQL dialect)	SQL	GraphQL
Historical Data Depth	Full chain history	Full chain history	From subgraph deployment
Update Latency	~5-15 minutes	~15-60 minutes	Near real-time (indexed blocks)
Free Tier Query Limit	Unlimited (rate-limited)	Unlimited (rate-limited)	~100k queries/month
Custom Dashboard Support	Yes	Yes	No (API/Subgraph endpoint)
Native Cross-Chain Support	Multi-chain datasets	Multi-chain datasets	Per-subgraph, chain-specific
Complex Aggregation Support	High-performance engine	Standard SQL performance	Limited by subgraph logic

SECTION-COMMON-CHALLENGES

Common Challenges and Solutions

Further Resources

Uniswap Protocol Documentation

Technical documentation on Uniswap v2 and v3 pool mechanics, fee models, tick math, and on-chain data structures needed for historical performance analysis.

Visit resource

The Graph Documentation

Guides on indexing on-chain data using subgraphs, querying historical AMM pool data with GraphQL, and working with time-series blockchain datasets.

Visit resource

Dune Analytics Documentation

Documentation for writing SQL queries over decoded on-chain data to analyze LP returns, volume, fees, and pool-level historical metrics across chains.

Visit resource

DeFiLlama

Aggregated DeFi analytics platform providing historical TVL, volume, and protocol-level metrics useful for contextualizing pool performance.

Visit resource

Curve Finance Documentation

Detailed documentation on Curve pool designs, invariants, gauges, and data structures relevant for analyzing stable swap pool performance on-chain.

Visit resource

Ready to Start Building?

Let's bring your Web3 vision to life.

From concept to deployment, ChainScore helps you architect, build, and scale secure blockchain solutions.

Start Your Project View Our Work