Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dune.com/llms.txt

Use this file to discover all available pages before exploring further.

Cut through transfer noise to see real onchain payments. These curated datasets work at the transfer level — one row per onchain transfer — isolating genuine payment activity from generic stablecoin movement across three surfaces: crypto card spend, agentic (machine-to-machine) payments, and classified commerce flows.
Maintained by: Dune · Refresh: Daily · Chains: EVM chains (Ethereum, Base, Arbitrum, Optimism, Polygon, BNB, and others); Solana and Tron for select tables

Explore Payments on Dune

Access Payments data via the Dune app, API, or Datashare.

​
Available Datasets

Card Transactions

Unified crypto card activity across issuers, card programs, and chains — card spend, merchant settlement, and top-ups normalised into a shared schema.

Agentic Payments

Machine-to-machine onchain payment activity across open HTTP 402 payment standards — x402 and MPP (onchain Tempo rails only).

Commerce Flows

Classified stablecoin transfers for real commerce-related onchain activity — B2B, B2C, and C2B flows identified via protocol matches and behavioural heuristics on EVM chains.

​
Key Features

  • Single-count economic payment: one row per observable onchain payment event, with provider- or protocol-specific detection logic normalised into a shared output schema.
  • Layered confidence: every row carries a confidence field (high for protocol-explicit matches, medium for behavioural heuristics) and a heuristic_id so analysts know exactly which rule fired.
  • Composable, transfer-level data: every row sits at the transfer level — linked to the underlying token transfer via transfer_unique_key and tagged with the end-user wallet — so payments join cleanly to the rest of Dune. Trace where users get funded from (tokens_evm.transfers), what DEXs and protocols they interact with (dex.trades), and into stablecoin analytics pipelines.
  • Stable cross-rail schema: provider- and protocol-specific fields are populated where available and NULL elsewhere — the unioned schema is stable across rails.

​
When to Use These Tables

  • Measuring onchain payment volume by network, provider, protocol, or chain.
  • Comparing adoption across payment rails (card payments vs agentic payments vs commerce flows).
  • Calculating the share of total onchain payments represented by a given rail or protocol.
  • Labelling stablecoin transfers as payment-related for downstream analytics.

​
Methodology

Each dataset is built in layers: protocol- or provider-specific per-chain incremental models, per-chain union views, and a final multichain view (payments.<dataset>). Detection and attribution logic varies by rail, but each layer conforms to the shared output schema. See each table’s page for rail-specific methodology. payments.commerce_flows feeds back into stablecoins_evm.activity_enriched, replacing category = 'unidentified' with category = 'payment' for matched transfers.

​
Example Queries

​
Payment volume by rail

SELECT
    protocol,
    SUM(amount_usd)   AS volume_usd,
    COUNT(*)          AS tx_count
FROM payments.commerce_flows
WHERE block_date >= NOW() - INTERVAL '30' DAY
GROUP BY 1