Live · Ethereum mainnet · block-aligned epochs

BDS · Uniswap V3

Live Uniswap V3 market on Powerloom: snapshotter nodes read Ethereum pools, DSV validators finalize canonical snapshots on-chain, and a full-node resolver serves metered HTTP for apps and agents.

This page is a transparency surface — contracts, live epoch signals, and where to consume the market. Project IDs use type:contract:namespace.

Verify a CID → Metered API routes Get agent API key

Agent API keys unlock metered /mpp/... consumption (HTTP, MCP, or CLI). They are not used for the on-chain reads shown in the panel below.

Current epoch (on-chain)

ProtocolState.currentEpoch · anchor RPC · not the resolver cache

Last finalized (on-chain)

lastFinalizedSnapshot + epochInfo per project ID

Exports

What's live

Uniswap V3 on Ethereum mainnet, finalized through Powerloom’s decentralized sequencer network. Per-pool work anchors on DSV mainnet; cross-pool products (e.g. allTradesSnapshot) are rolled up by the full-node resolver and exposed under /mpp/... for consumers.

DSV mainnet · per-pool snapshots

Lite-node slot work and baseSnapshot project IDs (example pool below).

Namespace: mainnet-BDS_MAINNET_UNISWAPV3-ETH
Example pool (baseSnapshot): 0x000cfcd0a6222e24b39b010a2410cd66062c7294
Data market: 0x26c44e5CcEB7Fe69Cffc933838CF40286b2dc01a
Protocol state: 0x1d0e010Ff11b781CA1dE34BD25a0037203e25E2a
Anchor RPC: https://rpc-v2.powerloom.network Powerloom mainnet · read-only browser calls
Source chain: Ethereum mainnet · pools via Uniswap V3 factory
Compute: PairTotalReservesProcessor · branch bds_eth_uniswapv3_core
Minted slots: Loading… getTotalNodeCount() via https://rpc-v2.powerloom.network
Enabled snapshotters: Loading… getTotalSnapshotterCount()
Per-epoch slot selection: Deterministic Fisher–Yates in the BDS compute package (SLOTS_PER_EPOCH and pool assignment). Not exposed on ProtocolState. Observed eligible slots per epoch appear in the participation table below.
Epoch cadence: Block-aligned (~12s)
IPFS gateway pattern: https://ipfs.io/ipfs{cid}

Mainnet alpha · resolver aggregates

Full node (core-edge) rolls up base snapshots into consumable products — allTradesSnapshot and other aggregates use this namespace and data market.

Namespace: mainnet-BDS_MAINNET_ALPHA_UNISWAPV3-ETH
Data market: 0x4198Bf81B55EE4Af6f9Ddc176F8021960813f641
Protocol state: 0xa1100CB00Acd3cA83a7C8F4DAA42701D1Eaf4A6c

Consensus validators

After snapshotters submit pool data each epoch, independent DSV validators agree on the canonical IPFS CIDs that get anchored on Powerloom mainnet. The table below is recent participation evidence from the public activity dashboard — who showed up and finalized batches in the tally window, not a full on-chain validator registry.

Loading watcher data…

Snapshotter participation

Snapshotter nodes run compute modules that turn Uniswap pool state into per-epoch snapshots and publish them into the network. Each row is one epoch: how many slots could submit vs how many did — a quick signal that the market is producing data. On-chain minted and enabled counts are in the market cards above.

Loading watcher data…

Network mesh

Snapshot submissions propagate over libp2p gossipsub before validators finalize them. The participation card summarizes recent validator and slot activity from the public dashboard API.

Gossipsub submissions

/powerloom/dsv-mainnet-bds/snapshot-submissions/all

Compute packages

Compute modules are the Python processors snapshotter nodes run each epoch to build market-specific payloads (reserves, trades, aggregates) before anything hits IPFS or DSV.

Package	Repo / branch	Class	Underlying contracts
Uniswap V3 pair totals	snapshotter-computes · `bds_eth_uniswapv3_core`	`PairTotalReservesProcessor`	Uniswap V3 factory + pool contracts

Consuming this market (metered API)

Provenance: Ethereum Uniswap V3 → snapshotter compute → DSV-finalized CIDs on Powerloom → IPFS payloads → the full-node resolver serves JSON and SSE at /mpp/....

Consumption: agents and apps call these routes with a Bearer API key (direct HTTP, hosted MCP, OpenClaw skills, or the bds-agent CLI). Each route below is billed in credits, not as a flat per-call fee.Base GET ≈ 0.0001388888888888889 credits per weight-1; SSE streams ≈ 0.01 per session.

Route	Description	Credits
`GET /mpp/pool/{pool_address}/metadata`	MPP: metadata for a single Uniswap V3 pool	×1
`GET /mpp/token/{token_address}/pools`	MPP: pools that include a given token (step 1 before per-pool token/price; required for USDC/WETH and other hub tokens)	×1
`GET /mpp/ethPrice`	MPP: ETH price snapshot for the latest finalized epoch	×5
`GET /mpp/ethPrice/{block_number}`	MPP: ETH price snapshot at a specific block (epoch)	×10
`GET /mpp/token/price/{token_address}/{pool_address}`	MPP: USD price for one token in one pool (latest epoch). Preferred over tokenPrices/all; pair with GET /mpp/token/{token}/pools	×5
`GET /mpp/token/price/{token_address}/{pool_address}/{block_number}`	MPP: USD price for one token in one pool at a block (Pulse/Guard). Pair with GET /token/{token}/pools	×10
`GET /mpp/snapshot/base_all_pools/{token_address}`	MPP: base snapshots for all pools of a token	×1
`GET /mpp/snapshot/base/{pool_address}`	MPP: base snapshot for a pool at the latest finalized epoch	×1
`GET /mpp/snapshot/base/{pool_address}/{block_number}`	MPP: base snapshot for a pool at a specific block	×1
`GET /mpp/snapshot/trades/{pool_address}`	MPP: trades snapshot for a pool at the latest finalized epoch	×1
`GET /mpp/snapshot/trades/{pool_address}/{block_number}`	MPP: trades snapshot for a pool at a specific block	×1
`GET /mpp/snapshot/allTrades`	MPP: all-pool trades snapshot at the latest finalized epoch (Bearer metering)	×1
`GET /mpp/snapshot/allTrades/{block_number}`	MPP: all-pool trades snapshot for a given epoch (block number)	×1
`GET /mpp/stream/allTrades`	SSE stream of all-pool trades per finalized epoch (flat session debit; credit_weight ignored by metering)	0.01 / session
`GET /mpp/tokenPrices/all/{token_address}`	MPP: USD prices across all pools (<=20 pools only). NOT for USDC/WETH/hub tokens — use /mpp/token/{token}/pools then /mpp/token/price/{token}/{pool}	×10
`GET /mpp/tokenPrices/all/{token_address}/{block_number}`	MPP: USD prices across all pools at a block (<=20 pools). NOT for USDC/WETH/hub tokens — use /mpp/token/{token}/pools then /mpp/token/price/{token}/{pool}/{block}	×10
`GET /mpp/tradeVolumeAllPools/{token_address}/{time_interval}`	MPP: aggregated trade volume across all pools for a token over a time window (seconds)	×1
`GET /mpp/tradeVolume/{pool_address}/{time_interval}`	MPP: aggregated trade volume for a pool over a time window (seconds)	×1
`GET /mpp/poolTrades/{pool_address}/{start_timestamp}/{end_timestamp}`	MPP: trades for a pool between Unix start and end timestamps	×1
`GET /mpp/timeSeries/{token_address}/{pool_address}/{time_interval}/{step_seconds}`	MPP: token price time series for a pool with interval and step (seconds). Dashboard/analytics; use token/price/{block} for trading.	×5 × lookback
`GET /mpp/dailyActiveTokens`	MPP: paginated daily active tokens (sorted by frequency)	×1
`GET /mpp/dailyActivePools`	MPP: paginated daily active pools (sorted by frequency)	×1

Hosted resolver base: https://bds-api.powerloom.io — prepend to routes above. Authenticate with Authorization: Bearer sk_live_… from the metering signup flow.

Route table source: build snapshot.

Time series routes (dashboards & analytics)

/mpp/timeSeries/... is for charting price over a window — the resolver walks more historical epochs, so credits scale with lookback ( time_interval). Agents and trading flows usually prefer per-epoch /mpp/token/price/.../{block_number}.

Effective debit ≈ base weight ×5 × multiplier below.

Lookback window (`time_interval`)	Multiplier	Effective (×5 base)
≤ 10 min (600s)	1×	5
≤ 30 min (1800s)	2×	10
≤ 1 hour (3600s)	4×	20
≤ 2 hours (7200s)	8×	40
≤ 4 hours (14400s)	16×	80
≤ 6 hours (21600s)	32×	160
≤ 12 hours (43200s)	64×	320
≤ 1 day (86400s)	128×	640
≤ 2 days (172800s)	256×	1280
≤ 4 days (345600s)	512×	2560
≤ 7 days (604800s)	1024×	5120
> 7 days (604800s)	2048×	10240

Multipliers from billing_modifier on the time series route in endpoints.json.

Resolver (how apps reach the data)

The snapshotter full node is the serving layer: it reads finalized on-chain CIDs, pulls IPFS payloads, and exposes the product API your agent or app calls. That is separate from DSV finalization and from lite-node snapshot production. Rolled-up aggregates use namespace mainnet-BDS_MAINNET_ALPHA_UNISWAPV3-ETH.

Resolver	Region	Uptime	MCP
Powerloom BDS resolver (core API)	Operator-hosted	—	https://bds-mcp.powerloom.io/sse

Build with agents

Reference integrations that consume this market through the same metered /mpp/... surface — skills, libraries, MCP, and sample apps.

Name	Type	Distribution	Status	Maintainer
powerloom-bds-univ3 Two validated one-shot prompts (free-key cron + wallet pay-signup cron).	skill	ClawHub (OpenClaw) · v0.2.4	published	Powerloom
bds-agent-py signup, signup-pay, query, create, run against verified /mpp routes.	library	PyPI / GitHub releases	published	Powerloom
bds-mcp-server verify_data_provenance + metered tools.	framework	Hosted SSE · Cursor / Claude Code / LangGraph-compatible MCP clients	published	Powerloom
pooler-frontend-v3 Reference consumption UI on Powerloom time-series data.	dashboard	GitHub	published	Powerloom
LangGraph adapter See Agents & BDS composability plan in docs.	framework	Planned	planned	Powerloom
CrewAI tool See Agents & BDS composability plan in docs.	framework	Planned	planned	Powerloom

Verification

Verify a CID

Paste an IPFS CID with pool + epoch, or paste an /mpp/... response JSON. We call ProtocolState.maxSnapshotsCid via the public Powerloom anchor RPC (https://rpc-v2.powerloom.network) — read-only, no API keys in this site.

Paste CID, JSON, or fill fields below

Project ID (pool) Epoch ID Expected CID