LP Intelligence Documentation

1. Overview

1.1 What is LP Intelligence

LP Intelligence is a structured data API for DeFi teams integrating liquidity and market data.

It provides indexed, queryable access to pools, swaps, token metadata, and chain data — without requiring teams to build and maintain custom on-chain indexers.

The API abstracts raw on-chain events into protocol-aware data models designed for:

DeFi dashboards and frontends
Analytics and research teams
Backend systems and internal tooling
Teams integrating or evaluating Uniswap v4

The goal is to reduce integration time from months of indexing and ETL work to days of API integration.

Broader liquidity models — including positions and fee state — are part of the expanding API surface and are currently in progress.

1.2 Supported Protocols

LP Intelligence currently supports:

Uniswap v4 (initial integration)

The architecture is designed for multi-protocol expansion. Future integrations will follow the same structured data model principles to ensure consistency across protocols.

1.3 Current Beta Status

LP Intelligence is currently in Public Beta.

Current characteristics:

Read-only API
Historical indexing available
Data freshness may lag (see Data Freshness section)
API access granted via request

Uniswap v4 hooks (current limitation):
LP Intelligence currently indexes core Uniswap v4 protocol contracts (e.g., PoolManager) and does not yet interpret or model hook-specific logic.

If a pool uses hooks that alter swap or liquidity behavior, derived fields may not fully reflect hook-level custom semantics. The hooks address is exposed as metadata when available.

1.4 Current Beta Scope

This section summarizes what is currently available and what is coming next.

Live — public beta API

Protocol: Uniswap v4 (Ethereum mainnet)
Read-only, historically indexed
GET /api/v1/uniswap-v4/pools — indexed liquidity pools
GET /api/v1/uniswap-v4/pools/{pool_id}/swaps — swap history per pool
GET /api/v1/uniswap-v4/accounts/{address}/swaps — swap history per account
GET /api/v1/uniswap-v4/tokens — token metadata for indexed pools
GET /api/v1/chains — supported chain metadata

In progress

GET /api/v1/uniswap-v4/accounts/{address}/positions — LP position history per account
GET /api/v1/uniswap-v4/positions/{position_id}/fees — fee state per position

Planned

Near real-time ingestion
Impermanent loss and PnL analytics
Multi-protocol expansion

1.5 Design Principles

LP Intelligence is built with the following principles:

Deterministic indexing

All responses are derived from deterministic indexing pipelines. Data is processed in strict block order to ensure consistency and reproducibility.

Structured, protocol-aware models

Rather than exposing raw contract events, the API provides:

Normalized pool objects
Structured swap data
Canonical token metadata
Chain metadata

This reduces client-side transformation logic and simplifies integration.

Positions and fee state are part of the expanding API surface and are currently in progress.

Transparent data freshness

Each response includes indexing metadata:

indexed_to_block — the highest block included in the dataset
indexed_at — the timestamp when indexing completed

This allows clients to reason about freshness and build their own consistency guarantees.

Developer-first API design

Predictable pagination (limit, next_cursor)
Consistent response envelopes
Clear error formats
Versioned endpoints

The API is designed for application and backend integration.

2. Quickstart

This section demonstrates how to make your first request to the LP Intelligence API and understand the response structure.

The API is REST-based and returns JSON responses.

2.1 Base URL

All requests should be sent to:

https://api.lp-intelligence.com

All endpoints are versioned. The current version is:

/api/v1

Example full URL:

https://api.lp-intelligence.com/api/v1/uniswap-v4/pools

2.2 Authentication

During Public Beta, API access is granted via API key.

Requests must include your API key in the Authorization header:

Authorization: Bearer YOUR_API_KEY

Example:

curl https://api.lp-intelligence.com/api/v1/uniswap-v4/pools \
  -H "Authorization: Bearer YOUR_API_KEY"

If authentication fails, the API will return 401 Unauthorized.

2.3 First Request Example

The following example retrieves a list of indexed pools on Ethereum mainnet (chain_id=1).

curl "https://api.lp-intelligence.com/api/v1/uniswap-v4/pools?chain_id=1&limit=10" \
  -H "Authorization: Bearer YOUR_API_KEY"

Query parameters:

chain_id — numeric chain identifier (e.g., 1 for Ethereum mainnet)
limit — number of results to return (max value defined by rate limits)

2.4 Example Response

A successful response returns HTTP 200 OK and a JSON body:

{
    "indexed_to_block": 21955247,
    "indexed_at": "2025-03-01T23:16:47Z",
    "items": [
        {
            "chain_id": 1,
            "pool_id": "0xfa86f15833604c1ee16f0a2f7de9d04d244fd9248a3ffe71220f7718f21871fe",
            "pool_manager": "0x000000000004444c5dc75cb358380d2e3de08a90",
            "fee": 100,
            "tick_spacing": 1,
            "hooks": null,
            "created_block": 21954731,
            "created_timestamp": "2025-03-01T21:33:23Z",
            "token0": {
                "address": "0x6111f3e70fbe68c8d62c3340b32e978ddfd8b08a",
                "symbol": "SETH",
                "decimals": 18,
                "name": "Sethereum"
            },
            "token1": {
                "address": "0xdb99b0477574ac0b2d9c8cec56b42277da3fdb82",
                "symbol": "DECT",
                "decimals": 18,
                "name": "DEC Token"
            }
        },
        {
            "chain_id": 1,
            "pool_id": "0x08d3552d8874b93fdbd8947916c89a375b3c96c34fb49cdf5b8ca79aef020b5c",
            "pool_manager": "0x000000000004444c5dc75cb358380d2e3de08a90",
            "fee": 10000,
            "tick_spacing": 200,
            "hooks": null,
            "created_block": 21954709,
            "created_timestamp": "2025-03-01T21:28:59Z",
            "token0": {
                "address": "0x0000000000000000000000000000000000000000",
                "symbol": "ETH",
                "decimals": 18,
                "name": "Ether"
            },
            "token1": {
                "address": "0x940a2db1b7008b6c776d4faaca729d6d4a4aa551",
                "symbol": "DUSK",
                "decimals": 18,
                "name": "Dusk Network"
            }
        },
        ...
        {
            "chain_id": 1,
            "pool_id": "0xe16b9af685b248d4f3e54890353f6f5086a8608d05ed806c4876ce99d4e6c12a",
            "pool_manager": "0x000000000004444c5dc75cb358380d2e3de08a90",
            "fee": 3000,
            "tick_spacing": 60,
            "hooks": null,
            "created_block": 21953412,
            "created_timestamp": "2025-03-01T17:08:35Z",
            "token0": {
                "address": "0x0000000000000000000000000000000000000000",
                "symbol": "ETH",
                "decimals": 18,
                "name": "Ether"
            },
            "token1": {
                "address": "0xb9f599ce614feb2e1bbe58f180f370d05b39344e",
                "symbol": "PORK",
                "decimals": 18,
                "name": "PepeFork"
            }
        },
        {
            "chain_id": 1,
            "pool_id": "0x4a24fcf3c1cbebd80d09537c7aa15adf2d228aa1b9ba1b0e5fb82e66dc96c0d2",
            "pool_manager": "0x000000000004444c5dc75cb358380d2e3de08a90",
            "fee": 500,
            "tick_spacing": 10,
            "hooks": null,
            "created_block": 21953133,
            "created_timestamp": "2025-03-01T16:12:47Z",
            "token0": {
                "address": "0x2260fac5e5542a773aa44fbcfedf7c193bc2c599",
                "symbol": "WBTC",
                "decimals": 8,
                "name": "Wrapped BTC"
            },
            "token1": {
                "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
                "symbol": "USDT",
                "decimals": 6,
                "name": "Tether USD"
            }
        }
    ],
    "next_cursor": "eyJjYiI6MjE5NTMxMzMsInBpZCI6IjB4NGEyNGZjZjNjMWNiZWJkODBkMDk1MzdjN2FhMTVhZGYyZDIyOGFhMWI5YmExYjBlNWZiODJlNjZkYzk2YzBkMiJ9",
    "limit": 10
}

Response envelope

All list endpoints return a consistent response envelope:

indexed_to_block — highest indexed block included in the dataset
indexed_at — timestamp when indexing completed
items — array of result objects
next_cursor — pagination cursor (if more results exist)
limit — number of items requested

This structure is consistent across endpoints.

2.5 Pagination Basics

List endpoints support cursor-based pagination.

To retrieve additional results:

Inspect the next_cursor field in the response.
If not null, pass it as a query parameter in the next request.

Example:

curl "https://api.lp-intelligence.com/api/v1/uniswap-v4/pools?chain_id=1&limit=10&cursor=eyJvZmZzZXQiOjEwfQ==" \
  -H "Authorization: Bearer YOUR_API_KEY"

Pagination guarantees:

Results are returned in deterministic order.
next_cursor ensures no overlap between pages.
If next_cursor is null, no additional results are available.

3. Authentication

LP Intelligence uses API key–based authentication for all requests.

Each request must include a valid API key in the Authorization header. API keys must be kept secret and should not be exposed in public client-side code.

API keys are long-lived, revocable, and scoped to a single account.

3.1 API Keys

Access to LP Intelligence is granted via API key.

Each account is issued a unique secret key during onboarding.

Example key format:

bf_live_7f4c9a2e3d1b4f0c8a6d9e2f1b3c4d5e

API keys:

Are account-scoped
Can be revoked or rotated
Should be kept secret
Must never be exposed in client-side code

Security recommendations

Store API keys in secure server-side environment variables.
Do not embed keys in frontend applications.
Rotate keys if you suspect compromise.

If a key is revoked, all subsequent requests using that key will return 401 Unauthorized.

3.2 Request Headers

All authenticated requests must include the Authorization header:

Authorization: Bearer YOUR_API_KEY

Example request:

curl https://api.lp-intelligence.com/api/v1/uniswap-v4/pools \
  -H "Authorization: Bearer bf_live_7f4c9a2e3d1b4f0c8a6d9e2f1b3c4d5e"

Requests without a valid API key will receive:

401 Unauthorized

If the key is valid but exceeds rate limits, the API will return:

429 Too Many Requests

3.3 Rate Limits

Rate limits are enforced per API key.

Limits are defined based on your access tier.

Rate limiting ensures:

Fair resource allocation
System stability
Predictable performance

When a rate limit is exceeded, the API responds with:

429 Too Many Requests

Example response:

{
  "error": "rate_limit_exceeded",
  "message": "Request rate limit exceeded. Please retry later."
}

Future versions may include rate limit headers such as:

X-RateLimit-Limit
X-RateLimit-Remaining
X-RateLimit-Reset

Rate limits may be adjusted during Public Beta.

3.4 Access Tiers

LP Intelligence is currently in Public Beta. There is a single access tier.

Public Beta

Read-only access
Historical indexing
Rate limits enforced per API key (limits may evolve during beta)
Access granted via request on the LP Intelligence page

Commercial tiers may be introduced after the beta period. Details will be published prior to any general availability release.

4. Core Concepts

This section defines the core data models used throughout LP Intelligence.

Rather than exposing raw contract events, the API provides structured, protocol-aware objects designed for backend and product integration.

4.1 Chains

A Chain represents a supported blockchain network.

Each chain is identified by a numeric chain_id, consistent with EVM standards.

Example:

1 — Ethereum mainnet
(additional chains will be added in future phases)

Chain-level context determines:

Address namespace
Block height
Indexing boundaries
Protocol deployment addresses

All endpoints that return chain-specific data include a chain_id field.

4.2 Pools

A Pool represents a liquidity pool within a supported protocol.

Pools define:

pool_id — unique identifier
token0 and token1 — assets paired in the pool
fee — fee tier
tick_spacing — discrete price granularity
Protocol-specific metadata (e.g., hooks in Uniswap v4)

Pools are canonicalized in the API to provide:

Normalized token metadata
Structured fee configuration
Deterministic identification

Pools serve as the foundational market unit for swaps and broader liquidity models.

Hooks Support (Uniswap v4)

The hooks address is exposed as metadata when available.
LP Intelligence does not currently decode or model hook callback logic.
Indexed data reflects core protocol events and state; hook-driven behavioral adjustments are out of scope at this stage.
Hook-aware indexing and enriched semantics are planned in a future release.

4.3 Positions

Note: Account positions are not yet part of the live public beta API. This section documents the target data model for endpoints currently in progress. See Section 1.4 for current live coverage.

A Position represents a liquidity provider’s allocation within a pool.

Positions are defined by:

sender — protocol-level caller from the ModifyLiquidity event
initiator — address that created or modified the position (tx.from)
pool — associated pool object
tick_lower / tick_upper — price range
liquidity — amount of active liquidity
salt — protocol-specific unique position discriminator

Positions are range-bound and active only when the current pool price falls within the specified tick range.

The API abstracts protocol-specific storage details into a consistent position model.

4.4 Swaps

A Swap represents a token exchange executed within a pool.

Swaps include:

Associated pool
Input and output tokens
Amounts
Block context
Transaction metadata

Swaps are indexed in deterministic block order and can be queried:

At the account level
At the pool level

Swap data enables:

Volume analytics
Strategy logic
Market activity monitoring

4.5 Liquidity Ranges (`tick_lower` / `tick_upper`)

Note: Liquidity range concepts are most relevant to position-level data. Account positions are not yet part of the live public beta API but are currently in progress.

Liquidity in concentrated liquidity AMMs is allocated across a defined price range.

Each position specifies:

tick_lower — lower bound of price range
tick_upper — upper bound of price range

Liquidity is active only when the current pool price lies within this range. Ticks are discrete price intervals determined by the pool’s tick_spacing.

Full-range positions span the minimum and maximum tick boundaries supported by the protocol.

Understanding liquidity ranges is critical for:

LP profitability modeling
Impermanent loss estimation
Active liquidity calculations

These concepts are included here to document the in-progress position model and the upcoming analytics surface.

4.6 Indexing Metadata

All list endpoints return indexing metadata to allow clients to reason about data freshness and completeness.

Each response includes:

indexed_to_block — the highest block included in the dataset
indexed_at — timestamp when indexing completed

This metadata allows clients to:

Detect indexing lag
Build consistency guarantees
Implement freshness thresholds
Reconcile internal state with blockchain height

LP Intelligence prioritizes transparency in indexing boundaries rather than implying real-time guarantees.

5. Endpoints

All endpoints are versioned under:

/api/v1

All responses are returned as application/json.

List endpoints:

Support cursor-based pagination
Return deterministically ordered results
Include indexing metadata where applicable

For full request/response schemas and parameter details, see the API Reference.

👉 Full API Reference (OpenAPI / ReDoc)

5.1 Account-Scoped Endpoints

The {address} parameter accepts any valid EVM address (EOA or contract).

Important: The {address} parameter is interpreted strictly as the transaction initiator (tx.from), not as a protocol-level sender field.

Returned swap objects include both:

initiator — the transaction sender (tx.from)
sender — protocol-level address emitted in the event

These values may differ in router, vault, multisig, or relayer-based interactions.

GET /api/v1/uniswap-v4/accounts/{address}/swaps

Returns swap activity executed in transactions initiated by the specified address.

Provides execution-level swap history enriched with pool context.

5.2 Pools

GET /api/v1/uniswap-v4/pools

Returns indexed liquidity pools for a given chain.

Pools represent canonical market units within the supported protocol and include normalized token metadata.

Supports filtering by:

chain
token address

Note — Hooks (Uniswap v4):
The hooks field is returned as metadata. Hook execution logic is not currently modeled in computed semantics.

GET /api/v1/uniswap-v4/pools/{pool_id}/swaps

Returns indexed swap activity for a specific pool.

Enables:

Volume aggregation
Liquidity utilization analysis
Market activity monitoring

5.3 Reference Data

GET /api/v1/uniswap-v4/tokens

Returns token metadata for tokens observed in indexed Uniswap v4 pools on a given chain.

This is not a chain-wide token registry. Only tokens that appear as token0 or token1 in indexed pools are included.

Supports basic search by symbol or name.

Freshness is based on pool registry coverage (indexed_to_block / indexed_at reflect the Uniswap v4 pool watermark).

GET /api/v1/chains

Returns supported blockchain networks within LP Intelligence.

Enables programmatic discovery of:

supported chain IDs
human-readable names
native currency metadata
explorer URLs

6. Errors

LP Intelligence uses standard HTTP status codes to indicate success or failure of an API request.

Clients should always:

Inspect the HTTP status code
Parse the response body for structured error details
Implement retry logic where appropriate

6.1 HTTP Status Codes

The API uses the following status codes:

200 — OK

The request was successful.

400 — Bad Request

The request is malformed or contains invalid parameters.

401 — Unauthorized

Authentication credentials are missing or invalid.

403 — Forbidden

Authentication succeeded but the request is not permitted for the current API key or access tier.

404 — Not Found

The requested resource does not exist.

422 — Validation Error

The request parameters failed schema validation.

429 — Too Many Requests

Rate limit exceeded.

500 — Internal Server Error

Unexpected server-side error.

6.2 Error Response Format

Error responses are returned in JSON format.

For validation errors, the API follows a structured schema:

{
  "detail": [
    {
      "loc": ["query", "limit"],
      "msg": "ensure this value is less than or equal to 500",
      "type": "value_error.number.not_le"
    }
  ]
}

Fields:

loc — location of the invalid field (path, query, body)
msg — human-readable error message
type — machine-readable error classification

Clients should rely on:

HTTP status code for control flow
type for programmatic handling
msg for logging or debugging

6.3 Validation Errors (422)

A 422 Unprocessable Entity response is returned when request parameters fail validation.

Common causes:

Invalid address format
Exceeding limit constraints
Invalid enum value (e.g., unsupported protocol)

Example:

{
  "detail": [
    {
      "loc": ["query", "chain_id"],
      "msg": "field required",
      "type": "value_error.missing"
    }
  ]
}

Clients should treat validation errors as non-retryable unless request parameters are corrected.

6.4 Auth Errors (401/403)

401 Unauthorized

Returned when:

Authorization header is missing
API key is invalid
API key is revoked

{
  "error": "invalid_api_key",
  "message": "The provided API key is invalid."
}

403 Forbidden

Returned when:

API key is valid but lacks permission
Access tier does not allow requested resource
Chain or protocol not enabled for the key

Example:

{
  "error": "access_denied",
  "message": "Your API key does not have access to this resource."
}

Clients should not retry 401 or 403 errors without changing credentials or upgrading access.

6.5 Rate Limit Errors (429)

If a client exceeds the allowed request rate, the API returns:

429 Too Many Requests

Example:

{
  "error": "rate_limit_exceeded",
  "message": "You have exceeded your request limit. Please retry later."
}

Clients should implement exponential backoff when receiving 429 responses.

Recommended retry strategy:

Initial delay: 500–1000 ms
Exponential backoff with jitter
Maximum retry attempts: 3–5

Future versions may include rate limit headers such as:

X-RateLimit-Limit
X-RateLimit-Remaining
Retry-After

6.6 Idempotency / Retries guidance (even if you don’t support idempotency yet, retries matter)

All current endpoints are read-only (GET) and are therefore idempotent.

Safe to retry:

429 (rate limit)
500 (server error)
Network timeouts

Do not retry without modification:

400 (bad request)
401 (unauthorized)
403 (forbidden)
422 (validation error)

Recommended retry pattern:

Treat GET endpoints as safe to retry
Implement exponential backoff
Log request ID and error payload for diagnostics
Avoid aggressive retry loops under sustained 429 responses

7. Pagination & Filtering

Most list endpoints return potentially large result sets. LP Intelligence provides cursor-based pagination to keep responses fast, stable, and safe for production workloads.

Supported list endpoints use:

limit (page size)
cursor (opaque pointer to the next page)
next_cursor (returned by the API when more results are available)

7.1 limit

limit controls the maximum number of items returned in a single response.

Type: integer
Typical default: 50
Max values:
- Most list endpoints: up to 500
- Tokens search: up to 1000

Guidance:

Use smaller limit values for latency-sensitive UIs.
Use larger values for backfills/batch jobs, but expect larger payload sizes.

Example:

GET /api/v1/uniswap-v4/pools?chain_id=1&limit=100

7.2 cursor / next_cursor

cursor (request)

cursor is an opaque string used to request the next page of results. You should treat it as a black box (do not parse or generate it).

Type: string (nullable)
Provided by: next_cursor from the previous response

next_cursor (response)

If more results exist, the response includes a next_cursor. If you reached the end, next_cursor is null.

Example flow:

First page (no cursor):

GET /api/v1/uniswap-v4/accounts/{address}/swaps?chain_id=1&limit=50

Response includes:

{
  "items": [ /* ... */ ],
  "next_cursor": "eyJ2Ijo...opaque...",
  "limit": 50
}

GET /api/v1/uniswap-v4/accounts/{address}/swaps?chain_id=1&limit=50&cursor=eyJ2Ijo...opaque...

Important rules:

Always pass the same query parameters when paginating (same chain_id, filters, etc.).
Don’t reuse a cursor across different endpoints.
Don’t store cursors long-term for business logic; treat them as short-lived pagination pointers.

7.3 Ordering Guarantees

List endpoints return results in a consistent, deterministic order suitable for pagination.

What you can rely on:

Pagination is stable and consistent within a given endpoint and parameter set.
Cursor pagination is aligned with that ordering so you do not miss or duplicate items while paging.

What you should not assume:

Undocumented sort details are part of the public API contract.
Every endpoint returns newest-first or oldest-first unless that behavior is explicitly documented.

Practical guidance:

For UIs: assume “most relevant / most recent” unless the endpoint documentation states otherwise.
For ingestion jobs: page until next_cursor = null.

7.4 Deterministic Responses

LP Intelligence is an indexed data API, which means responses represent a snapshot at an indexing boundary, not necessarily the latest chain head.

To support deterministic integration behavior:

Many responses include indexing metadata (e.g., indexed_to_block, indexed_at), allowing you to detect when the underlying dataset advanced.
Pagination is designed to be consistent within an indexing window.

Responses include indexed_to_block, which indicates the highest indexed block included in the dataset. Clients performing large historical backfills may use this value to ensure consistency across paginated requests.

8. Data Freshness & Indexing

8.1 Historical Indexing Model

LP Intelligence currently operates on a historically indexed dataset.

The indexing pipeline processes on-chain events in strict block order, starting from the Uniswap v4 PoolManager deployment block. All data in the current beta reflects events that occurred before the current indexing boundary.

This means:

Responses represent a deterministic snapshot at an indexing boundary.
Data is not updated continuously or in near real time.
There may be a lag between the current chain head and the highest indexed block.

Near real-time ingestion is planned but not yet enabled in the current beta.

8.2 Current Freshness Window

The current dataset covers Ethereum mainnet from the Uniswap v4 PoolManager deployment through the current indexing boundary.

Indexing progress is reflected in the indexed_to_block and indexed_at fields returned in every list response.

As the indexing pipeline advances, these values will be updated. Clients may poll these fields to detect when new data becomes available.

8.3 How to Interpret indexed_to_block

Every list response includes two freshness fields:

indexed_to_block — the highest block number included in the dataset at the time of the response.
indexed_at — the UTC timestamp when indexing reached that block.

Practical guidance:

Use indexed_to_block to check whether the data you need is already included in the indexed dataset.
If you need multiple API responses to reflect the same indexed snapshot, compare indexed_to_block across those responses.
If indexed_to_block has not changed between requests, the indexed dataset has not moved forward to newer blocks.
Do not assume that indexed_to_block equals the current chain head.

Example:

{
  "indexed_to_block": 21955247,
  "indexed_at": "2025-03-01T23:16:47Z",
  "items": [ /* ... */ ]
}

8.4 Planned Near Real-Time Ingestion

Near real-time ingestion — continuously following the chain tip — is planned for a future phase.

When enabled, indexed_to_block will advance alongside the chain head with a short lag (measured in seconds or minutes rather than hours or days).

Until then, the beta dataset is updated periodically. The indexed_at field reflects the last update timestamp.

9. Versioning

All LP Intelligence API endpoints are versioned under a path prefix.

The current version is:

/api/v1

Example:

https://api.lp-intelligence.com/api/v1/uniswap-v4/pools

Versioning policy:

Non-breaking additions (new fields, new optional parameters) may be made within the current version without a version bump.
Breaking changes (removed fields, changed response structure, removed endpoints) will result in a new version path (e.g., /api/v2).
Old version paths will be supported with advance notice before deprecation.

During the public beta, the API is still evolving. Field additions are possible. Any breaking changes will be communicated to active API key holders before rollout.

10. Roadmap

This section summarizes the current state and direction of LP Intelligence.

Live — public beta

Uniswap v4 pools, pool swaps, account swaps, tokens, chains
Cursor-based pagination
Indexing metadata on every response
API key authentication

In progress

Account positions (/accounts/{address}/positions)
Position fee state (/positions/{position_id}/fees)

Planned

Near real-time ingestion (continuous chain-tip following)
Impermanent loss and PnL analytics
Multi-protocol expansion (beyond Uniswap v4)
Access tiers and usage dashboards

LP Intelligence Documentation

1. Overview

1.1 What is LP Intelligence

1.2 Supported Protocols

1.3 Current Beta Status

1.4 Current Beta Scope

Live — public beta API

In progress

Planned

1.5 Design Principles

Deterministic indexing

Structured, protocol-aware models

Transparent data freshness

Developer-first API design

2. Quickstart

2.1 Base URL

2.2 Authentication

2.3 First Request Example

2.4 Example Response

Response envelope

2.5 Pagination Basics

3. Authentication

3.1 API Keys

Security recommendations

3.2 Request Headers

3.3 Rate Limits

3.4 Access Tiers

Public Beta

4. Core Concepts

4.1 Chains

4.2 Pools

Hooks Support (Uniswap v4)

4.3 Positions

4.4 Swaps

4.5 Liquidity Ranges (tick_lower / tick_upper)

4.6 Indexing Metadata

5. Endpoints

5.1 Account-Scoped Endpoints

GET /api/v1/uniswap-v4/accounts/{address}/swaps

5.2 Pools

GET /api/v1/uniswap-v4/pools

GET /api/v1/uniswap-v4/pools/{pool_id}/swaps

5.3 Reference Data

GET /api/v1/uniswap-v4/tokens

GET /api/v1/chains

6. Errors

6.1 HTTP Status Codes

200 — OK

400 — Bad Request

401 — Unauthorized

403 — Forbidden

404 — Not Found

422 — Validation Error

429 — Too Many Requests

500 — Internal Server Error

6.2 Error Response Format

6.3 Validation Errors (422)

6.4 Auth Errors (401/403)

401 Unauthorized

403 Forbidden

6.5 Rate Limit Errors (429)

429 Too Many Requests

6.6 Idempotency / Retries guidance (even if you don’t support idempotency yet, retries matter)

7. Pagination & Filtering

7.1 limit

7.2 cursor / next_cursor

cursor (request)

next_cursor (response)

7.3 Ordering Guarantees

7.4 Deterministic Responses

8. Data Freshness & Indexing

8.1 Historical Indexing Model

8.2 Current Freshness Window

8.3 How to Interpret indexed_to_block

8.4 Planned Near Real-Time Ingestion

9. Versioning

10. Roadmap

Live — public beta

In progress

Planned

4.5 Liquidity Ranges (`tick_lower` / `tick_upper`)