Protocol & Liquidity Analytics

This page defines protocol-agnostic liquidity and usage analytics for Solana DeFi.

It normalizes protocol-specific semantics into stable pool datasets.

This layer exposes analytics objects. It does not expose execution internals or routing logic.

---

Coverage (what you get)

Acceso produces three core dataset types:

• Pool metadata

  • Protocol, program, pool address, token mints, fee model identifiers.

• Pool state snapshots

  • Reserves, TVL, and configuration parameters over time.

• Protocol and pool aggregates

  • Activity and liquidity time-series computed on explicit windows.

Common windows: 5m, 15m, 1h, 4h, 24h.

---

Adapter model (Solana-native normalization)

Each protocol is integrated via an isolated adapter. Adapters decode program instructions, logs, and pool accounts.

Normalization guarantees

• Stable identifiers: protocol, program_id, pool_address.

• Consistent asset identity: token mints + decimals.

• Comparable metrics across protocols using consistent formulas.

Pool reserve units are always normalized by mint decimals. Avoid mixing raw lamports with UI amounts.

---

Pool metadata (discovery and identity)

Pool discovery produces a minimal, durable identity record. This record is designed to be cached aggressively.

• pool_address, program_id, protocol

• token_a_mint, token_b_mint

• lp_mint (when applicable)

• fee_bps (or a protocol-specific fee model reference)

• created_slot / created_at (best-effort when observable)

Liquidity and TVL analytics

Liquidity analytics are built from pool account state and vault balances.

• Reserves

  • reserve_a_ui, reserve_b_ui

• TVL (best-effort)

  • USD TVL is computed only when price inputs exist.

• Liquidity distribution

  • Pool share vs protocol totals for the same assets.

• Change metrics

  • Net liquidity delta per window.

  • Liquidity volatility (variance of reserves over a window).

---

Example payloads (conceptual)

Example: pool snapshot (conceptual)

{
  "observed_at": "2025-12-17T10:05:00Z",
  "slot": 312345999,
  "protocol": "amm",
  "program_id": "ExampleProgramId",
  "pool_address": "ExamplePoolAddress",
  "token_a_mint": "So11111111111111111111111111111111111111112",
  "token_b_mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
  "reserves": {
    "token_a_ui": 512.4381,
    "token_b_ui": 103841.22
  },
  "tvl": {
    "usd": 207992.41,
    "confidence": 0.86
  },
  "params": {
    "fee_bps": 25
  }
}

Example: protocol aggregate (conceptual)

{
  "window": "1h",
  "start_time": "2025-12-17T09:00:00Z",
  "end_time": "2025-12-17T10:00:00Z",
  "protocol": "amm",
  "metrics": {
    "volume_usd": 18450231.22,
    "trade_count": 98124,
    "active_pools": 1432,
    "tvl_usd": 912345678.9
  }
}

---

Activity aggregates (protocol and pool)

These aggregates describe usage without relying on a single venue.

Common aggregates:

• Volume and trade count per window

• Active pools per window

• Venue concentration (pool share of pair volume)

• Window-over-window deltas for trend detection

---

Consumer guidance

TVL is a derived view. Reserve-based analytics remain valid without USD pricing.

Recommended defaults:

• Prefer windowed aggregates over raw event scans.

• Use pool_address + window boundaries as your dedupe key.

• Treat pricing-derived fields as best-effort with explicit confidence.