DeFi Analytics Service

Adapters typically implement:

Protocol logic is isolated behind adapters. Each adapter owns decoding and semantics.

Adapter model (non-negotiable)

It does not expose protocol execution details. It exposes normalized analytics objects.

  • Solana blocks, transactions, and account reads.

  • Program logs and instruction payloads.

  • Pool accounts and vault balances for liquidity state.

The service consumes:

Boundary and inputs

Acceso’s DeFi Analytics Service turns Solana DeFi programs into stable analytics products. It is the home of protocol adapters and derived datasets.

  • Pool discovery and metadata extraction.

  • Pool state snapshots (reserves, liquidity, parameters).

  • Normalized trade events (swaps, fills, route legs when possible).

  • LP actions (adds/removes) for flow analytics.

Adapters map protocol semantics into shared internal models. New protocol support should be additive and backward compatible.

Derived datasets (what the service produces)

The service computes derived views that are expensive to do on-demand:

  • Protocol-level volume and activity aggregates.

  • Pool-level liquidity and TVL time-series.

  • Trade-derived OHLCV and interval aggregates.

  • Behavioral signals (launch events, large-actor activity, anomaly signals).

The service prioritizes:

Normalization guarantees (what clients should assume)

  • Cross-protocol field consistency (mints, amounts, fees, prices).

  • Stable identifiers (protocol, pool_address, program_id).

  • Explicit windows for aggregates and signals.

Operational behavior

The service is designed for read-heavy workloads:

  • Cache-first for slow-changing metadata.

  • Short-lived caching for hot “latest” views.

  • Derived views cached by query signature when safe.

Failure isolation matters. Adapter failures should degrade a protocol’s coverage, not the whole platform.

Last updated